NSAuditor AI EE produces a §164.312 Technical Safeguards pre-audit gap report mapped to the HIPAA Security Rule (45 CFR §164.312, 2013 Final Rule). SHA-256 chain-of-custody sidecars, cover-page Scope Attestation, suppression workflow, R/A discipline enforced per HHS — and Zero BAA required because ePHI never leaves your infrastructure.
Current release — EE 0.33.1 (2026-08-07): auditor-verifiable proof, now stated in every framework report. All seven auditor-shaped reports now say the same thing about evidence integrity: RFC 3161 trusted timestamping is opt-in via NSAUDITOR_TSA_URL, pointed at a Time-Stamp Authority you choose, and every compliance artifact then carries a .tsr sidecar your auditor verifies offline with stock openssl — against that third party, with none of our software in the path. Opt-in with no default, ever, so an air-gapped environment simply leaves it unset. Verified end to end on 2026-08-07 against a real public Time-Stamp Authority through the published binaries. The agent skill and the Community Edition README answer the same way, so every surface a reader can reach agrees. It builds directly on EE 0.33.0 (2026-08-07), the wiring release. Eleven compliance options that nothing shipped could populate now receive values from a real entry point — the option existed, the engine read it, and nothing ever wrote to it. The new entry points live in Community Edition, so EE 0.33.0 requires CE ≥ 0.2.37; on an older CE the options stay unfed. Zero Data Exfiltration is no longer a denial but a positive register of 17 enumerated outbound paths, each named with its trigger and its off switch — the form an HHS-OCR reviewer can actually check against a Zero-BAA architecture. RFC 3161 trusted timestamping is now opt-in via NSAUDITOR_TSA_URL, verified against a real timestamp authority on 2026-08-07 — opt-in, not a default, and itself one of those outbound paths. Ed25519 suppression signing is still NOT reachable from any shipped entry point. Signature records now carry algorithm and backend frozen at signing time rather than re-derived later. Matrix-neutral — all seven coverage matrices UNCHANGED, plugin count UNCHANGED at 28 Enterprise plugins (27 of them cloud auditors), 55 overall; this HIPAA §164.312 matrix is UNCHANGED at 7 covered / 3 partial / 45 OOS. Paired CE 0.2.37 + agent-skill 0.2.35.
Prior — EE 0.32.11 (2026-08-05): a scan report has two jobs — find what is wrong, and be clear about what it did not look at. Ours was failing the second.
1. The summary was dropping a whole tier. The cloud-scan summary rendered CRITICAL, HIGH, MEDIUM, LOW and PASS. INFO was not a column — not zero, absent. On a real AWS account producing 62 INFO findings, 55 of them appeared in no summary anywhere, and several were the scanner’s own declarations of what it had not evaluated. INFO is now a column and rolls up by category.
2. “Not assessed” now has its own channel. Scope boundaries are labelled [SCOPE NOT ASSESSED] — deliberately not the evidence-gap badge, because “I could not verify this on this run” and “this release does not evaluate this at all” are different statements and an auditor needs to tell them apart. Surface nobody assessed must not read like surface assessed and found clean.
Also in that release: a new compliance_matrix tool returns the shipped coverage matrix for any of the seven frameworks, derived from the framework maps at call time rather than transcribed; a capability flag that was registered and printed but implemented nowhere is withdrawn, and every capability now ships a written description; and three GCP firewall verdicts that could read clean over unevaluated rules now fail closed. Matrix-neutral — 28 Enterprise plugins, 27 of them cloud auditors (55 overall), and seven frameworks, all unchanged. Paired CE 0.2.36 + agent-skill 0.2.34.
Prior — EE 0.32.11 (2026-08-05): the dependency-advisory release gate had been auditing the maintainer’s development tree while calling it the production closure. It now packs the tarball, installs it the way a customer does, and audits that — and refuses to report clean until an advisory database has actually answered.
Prior — EE 0.32.9 (2026-07-29): an internal-provenance strip plus a false-clean closure. A compliance report is a document you hand your assessor, and ours carried internal engineering identifiers — roadmap ids, internal release stamps, the name of an internal audit review — in finding titles, on the attestation cover page and in the chain-of-custody record. Measured on a rebuilt three-cloud evidence pack: 686 unexplained internal-marker occurrences → 0 across 105 files, with a positive control in the same run (3,572 benign matches still detected) so the zero is a measurement rather than an absence of looking. And when a cloud plugin could not start — optional SDK absent, credentials unusable — it refused to report, and that refusal evaporated one layer up: the compliance report came out byte-identical to one where the scanner ran and found nothing. Ten controls read PASS, no violation, no warning. For a §164.312 pack that is the worst possible failure mode, because the substrate an HHS-OCR reviewer relies on is exactly the substrate that silently was not collected. Every in-scope control of a cloud that could not be scanned now carries a fail-closed evidence gap. Also in that release: an archived scan re-processed by the new build WARNS instead of failing clean; four report surfaces that contradicted each other on trusted timestamping — which was still on the roadmap at that release, and became opt-in via NSAUDITOR_TSA_URL in EE 0.33.0 — now say the same verifiable thing; and a new pack scanner that fails closed when its own positive control comes back empty. The paired Community Edition 0.2.34 fixed --out <dir> writing to the parent directory when the directory name contains a dot. Two upgrade notes still apply: (1) the evidence-gap finding title changed at 0.32.9, so suppression rules written against the older text stop matching — the direction is safe (findings resurface rather than hide) but it is silent, so re-check your suppression list; (2) re-scan rather than re-processing scans captured before 0.32.9, as the engine now warns when it is handed an older archive.
Before that — EE 0.32.8 (2026-07-28): capability-claim honesty pass, part 2 — the air-gapped-delivery class. 27 advertised claims across the three published packages were checked against the code and withdrawn: an arm64 image (the build forces linux/amd64), offline-installable tarballs, monthly NVD feed bundles, an air-gapped install script, and a feed import CLI command with no implementation. Five of the 27 were not documentation but rendered runtime strings — the [COVERAGE GAP] rationale that prints verbatim into the assessor-facing evidence pack was telling the reader to import a feed with a command that does not exist. Nothing was withdrawn by deletion: the air-gap story was rewritten to what the code supports — a linux/amd64 delivery image or npm host install, fully offline ES256 license verification with no phone-home, and offline CVE matching under NSAUDITOR_OFFLINE_ONLY=1 — and ends with an explicit “deliberately not claimed” list, held by two mutation-proven guards. Matrix-neutral — no detection, routing or coverage change; still 28 EE plugins and all seven coverage matrices byte-identical to 0.32.7. This HIPAA §164.312 matrix is UNCHANGED at 7 covered / 3 partial / 45 OOS. The paired Community Edition also fixes --out, which silently wrote to the parent directory when the output directory was version-named. Regression 9,280 pass / 0 fail. Paired CE 0.2.33 + agent-skill 0.2.31. And before that: EE 0.32.7 (2026-07-21) — cross-framework routing, so network-scan findings reach every framework that maps their control subject; matrix-neutral.
HIPAA Security Rule §164.312 is a supported compliance framework alongside SOC 2. The engine reads data/compliance/hipaa.json with mappings inherited from soc2.json's grep-verified pattern set plus HIPAA-grounded rationales. Single scan with --compliance soc2,hipaa produces both evidence packs. See the SOC 2 coverage matrix for the SOC 2 framework.
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 hash-chained evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, and a documented suppression workflow — 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.
It is not a §164.308 Administrative Safeguards evidence source (workforce training, sanction policies, contingency planning, BAAs, security incident procedures — pair with Drata HIPAA, Vanta HIPAA, Compliancy Group, Tugboat Logic). It is not a §164.310 Physical Safeguards evidence source (facility access controls, workstation security, device/media disposal — pair with facility-management + endpoint-management + asset-disposal vendors). It is not a complete HIPAA Security Rule attestation (§164.312 is one of three safeguard families). It is not a substitute for a §164.308(a)(1)(ii)(A) HIPAA Risk Analysis (this scanner produces input data the analysis can consume but cannot itself BE the risk analysis).
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).
HIPAA Security Rule specifications carry one of two HHS-defined classifications:
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.
| §164.312 Spec | R/A | Standard / Implementation Specification |
|---|---|---|
| (a)(1) Access Control | R | Standard |
| (a)(2)(i) Unique User Identification | R | Implementation Specification |
| (a)(2)(ii) Emergency Access Procedure | R | Implementation Specification |
| (a)(2)(iii) Automatic Logoff | A | Implementation Specification |
| (a)(2)(iv) Encryption and Decryption | A | Implementation Specification |
| (b) Audit Controls | R | Standard |
| (c)(1) Integrity | R | Standard |
| (c)(2) Mechanism to Authenticate ePHI | A | Implementation Specification |
| (d) Person or Entity Authentication | R | Standard |
| (e)(1) Transmission Security | R | Standard |
| (e)(2)(i) Integrity Controls (transit) | A | Implementation Specification |
| (e)(2)(ii) Encryption (transit) | A | Implementation Specification |
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).
| Status | Count | §164.312 Sub-Criteria |
|---|---|---|
| ✓ Covered | 7 | §164.312(a)(1), (a)(2)(i), (a)(2)(iv), (b), (d), (e)(1), (e)(2)(ii) |
| ⚠ Partial | 3 | §164.312(c)(1), (c)(2), (e)(2)(i) |
| ⚪ OOS within §164.312 | 2 | §164.312(a)(2)(ii), (a)(2)(iii) |
| ⚪ OOS §164.308 entire | 31 | All Administrative Safeguards |
| ⚪ OOS §164.310 entire | 12 | All Physical Safeguards |
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.
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.
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.
The engine is 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:
| Framework | Citation slot | SLA cadence citation | Identity verification citation |
|---|---|---|---|
| SOC 2 | governance | CC7.1 remediation cadence | CC6.2 / CC6.3 |
| HIPAA | governance (sentinel) | §164.312(b) audit-controls cadence | §164.312(d) Person or Entity Authentication |
HIPAA reports do not cite SOC 2 control IDs — the auditor-detectable cross-framework citation leak is closed via the 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.
Each --compliance hipaa run writes the evidence bundle to out/<scan-id>/. Every artifact ships with a .sha256 integrity sidecar.
| File | Purpose |
|---|---|
| scan_compliance_hipaa.md | Human-readable HIPAA pre-audit gap report — cover-page Scope Attestation, per-control status (PASS/FAIL/PARTIAL/OOS) with §164.312 rule-text citations, per-violation evidence with HIPAA-grounded rationale, Appendix A Cloud Bucket Exposure, Appendix B Accepted Risks & False Positives. |
| scan_compliance_hipaa.html | Standalone HTML version with inline CSS — auditor-friendly visual presentation. |
| scan_compliance_hipaa.json | Machine-readable for GRC platform ingestion. |
| *.sha256 | Per-artifact SHA-256 sidecars — verify with shasum -a 256 -c <file>.sha256. |
| scan_attestation_hipaa.json | Scope envelope: targets, exclusions, scanner version, scan window, framework + label + version. |
| scan_chain_of_custody_hipaa.json | Links scan-id → finding manifest → suppressions → artifact hashes. |
All artifacts can run side-by-side with the SOC 2 artifacts when --compliance soc2,hipaa is used.
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.
"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)."
| Source | Example finding | Why it violates §164.312(a)(1) |
|---|---|---|
| auth_agent | SSH password authentication enabled | Password-only SSH violates least-privilege boundary enforcement on the host-access layer to ePHI-bearing systems. |
| aws-iam-deep-auditor | SHADOW ADMIN: User has full wildcard (*) permissions | Shadow admins aggregate effective-admin permissions across attached/inline policies, bypassing intended access restrictions to ePHI-bearing resources (cross-references §164.308(a)(4)). |
| aws-iam-deep-auditor | Shadow admin path (PassRole): user/devops can PassRole + lambda:CreateFunction → admin role | PassRole-mediated privesc — textbook Rhino Security Labs IAM privesc primitive that bypasses access-control boundary on ePHI-bearing workloads. |
| azure-rbac-auditor | RBAC: Owner role assigned at subscription scope | Owner role at subscription scope violates §164.308(a)(4)(ii)(C) — auditors expect just-in-time PIM elevation or limited break-glass identities only. |
| azure-keyvault-auditor | Key Vault network ACL default action is Allow | Key Vault houses cryptographic material protecting ePHI; the access boundary is the network ACL — default=Allow defeats the boundary. |
| gcp-iam-project-auditor | Project IAM policy has bindings granting the 'allUsers' sentinel | Grants role permissions to unauthenticated internet callers — full bypass of access control on any ePHI-bearing GCP project resource. |
| gcp-iam-project-auditor | SA-impersonation path detected | Multi-hop SA-impersonation paths give a principal effective admin to ePHI-bearing GCP resources — equivalent to AWS shadow-admin AssumeRole chains. |
| aws-apigateway-auditor | method 'GET /ePHI-endpoint' has AuthorizationType: NONE | API Gateway method with NONE-auth exposes ePHI integration directly to unauthenticated callers — canonical serverless §164.312(a)(1) violation. |
| aws-lambda-auditor | Lambda function has a public Function URL with AuthType: NONE | Exposes the function to unauthenticated callers — parallel to API Gateway NONE-auth class. |
| aws-iam-effective-decrypt-auditor | IAM principal has effective kms:Decrypt on Resource:* | Account-wide decrypt blast-radius — ePHI confidentiality boundary scope gap (also fires §164.312(a)(2)(iv)). |
| aws-ec2-sg-perimeter-auditor | Security Group has all-protocol (-1) ingress from 0.0.0.0/0 | Catastrophic network-segmentation gap on ePHI-bearing ENIs — every port exposed to public internet. |
| gcp-cloud-storage-auditor | Bucket has IAM binding(s) granting the 'allUsers' sentinel | GCS bucket public exposure — full bypass of access control on bucket-resident ePHI. |
| aws-backup-auditor | Backup vault access policy contains Allow statement(s) granting WILDCARD-Principal | Wildcard-Principal on backup vault permits any AWS account to interact with the vault — defeats the access-control boundary on ePHI backup material. |
"Assign a unique name and/or number for identifying and tracking user identity."
| Source | Example finding | Why it violates §164.312(a)(2)(i) |
|---|---|---|
| auth_agent | SNMP default community string 'public' detected | Shared anonymous credentials defeat the user-identification requirement on monitored ePHI-bearing infrastructure. |
| auth_agent | Anonymous FTP access enabled | Anonymous FTP grants access with NO user identity — all activity attributes to 'anonymous'. |
| aws-ec2-sg-perimeter-auditor | Security Group is not attached to any ENI (orphan SG) | Auditors cannot map orphan SG to a specific workload identity, breaking the auditable-identity chain expected for ePHI-bearing AWS resources. |
"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).
| Source | Example finding | Why it violates §164.312(a)(2)(iv) |
|---|---|---|
| aws-s3-auditor | No default encryption / Server-side encryption not enabled | Direct absence of the encryption mechanism for at-rest ePHI in S3. |
| aws-kms-auditor | Customer-managed KMS key has automatic key rotation DISABLED | Disabled rotation on a CMK protecting ePHI means key bytes never rotate; compromised key remains valid indefinitely. |
| aws-kms-auditor | KMS key policy grants Principal: AWS:* + kms:* | Catastrophic encryption-mechanism failure — any AWS principal can decrypt ePHI protected by this key. |
| aws-rds-auditor | RDS DB instance has storage encryption DISABLED | RDS stores ePHI in cleartext on EBS volumes — direct absence of the encryption mechanism. |
| aws-sqs-sns-auditor | SQS queue / SNS topic has encryption-at-rest DISABLED | Message-bus payloads (potentially carrying ePHI in transit between systems) stored in cleartext at the SQS/SNS storage layer. |
| aws-elasticache-redis-auditor | ElastiCache Redis has at-rest encryption DISABLED | Cached ePHI stored in cleartext. |
| azure-keyvault-auditor | Key Vault purge protection NOT enabled | Permitting permanent destruction of ePHI-protecting key material during 7-90 day retention results in irrevocable encrypted-ePHI loss. |
"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).
| Source | Example finding | Why it violates §164.312(b) |
|---|---|---|
| aws-cloudtrail-auditor | no trails configured for this account | Catastrophic gap — ZERO record of API activity in AWS account hosting ePHI. |
| aws-cloudtrail-auditor | does not log data events | Granularity gap — management-only CloudTrail misses data-plane (GetObject, GetItem) ePHI access activity. |
| aws-cloudtrail-auditor | log file validation disabled | Cross-references §164.312(c)(1) — log-file-validation enables tamper-detection on the audit log itself. |
| aws-rds-auditor | RDS DB instance (postgres) has pgAudit DISABLED | Database-layer audit gap — pgAudit provides session + object-level audit logging on ePHI tables. |
| aws-rds-auditor | CloudWatch Logs retention below institutional baseline | Audit-retention gap — records age out before HHS-recommended retention horizon (§164.530(j) — 6-year administrative requirement; technical floor must support it). |
| aws-inspector-guardduty-auditor | GuardDuty is NOT ENABLED in region | Cross-references §164.308(a)(1)(ii)(D) Information System Activity Review (admin OOS but technically substrated here). |
"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).
| Source | Example finding | Why it violates §164.312(d) |
|---|---|---|
| aws-iam-deep-auditor | no MFA configured / WITHOUT MFA | Single-factor authentication cannot verify identity to HHS-expected standard for ePHI-access-bearing AWS IAM users. |
| aws-secrets-auditor | Secrets Manager secret has rotation DISABLED / rotation is OVERDUE | Long-lived credentials defeat entity-authentication freshness invariant on ePHI access paths. |
| aws-rds-auditor | RDS DB instance has IAMDatabaseAuthenticationEnabled=true | PASS substrate — short-lived IAM-mediated auth tokens (15-min expiry) replace long-lived passwords for ePHI-bearing RDS instances. |
| aws-elasticache-redis-auditor | ElastiCache Redis has NO authentication configured | Authentication-absent gap — relies SOLELY on Security Group perimeter; defeats entity-authentication entirely on ePHI cache. |
"Implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network."
| Source | Example finding | Why it violates §164.312(e)(1) |
|---|---|---|
| crypto_agent | TLSv1.0 / TLSv1.1 / SSLv3 / SSLv2 | Deprecated TLS/SSL with known cryptographic vulnerabilities (POODLE, BEAST) — ePHI in transit exposed to MITM. |
| crypto_agent | Weak cipher suites | RC4 / 3DES / EXPORT-grade nominally encrypts but is cryptographically broken — ePHI in transit at plaintext-recovery risk. |
| aws-rds-auditor | RDS DB instance does NOT enforce SSL connections | Database-transit gap — ePHI transmitted between application and database exposed if client opts out of TLS. |
| aws-sqs-sns-auditor | SQS queue has Policy without Deny on aws:SecureTransport | Message-bus transit gap — permits cleartext HTTP API calls; ePHI in queue messages may transit unencrypted. |
| aws-ses-auditor | SES configuration set TlsPolicy=OPTIONAL | Email-transit policy — OPTIONAL falls back to cleartext SMTP if receiver lacks TLS support. |
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.
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.
"Implement policies and procedures to protect ePHI from improper alteration or destruction."
Partial because: Infrastructure scanning evidences the STORAGE-SUBSTRATE integrity dimension (backup-vault immutability, PITR, replication, snapshot retention, KMS-grants integrity on backup keys, GCS retention policies) but cannot evidence APPLICATION-LAYER integrity (per-record checksumming, tamper-detection on database rows, ePHI-payload integrity verification at access time).
"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.
"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.
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:
A composite-attestation PASS evidences that ePHI backups would survive a full source-account compromise — exactly the §164.312(c)(1) integrity-preservation posture HHS-OCR expects post-ransomware-incident.
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).
| Spec | R/A | OOS Reason |
|---|---|---|
| §164.312(a)(2)(ii) Emergency Access Procedure | R | Procedural break-glass-runbook control — pair with documented break-glass procedure + workforce training records. |
| §164.312(a)(2)(iii) Automatic Logoff | A | Session-timeout configuration at the application or OS tier — not addressable by API-based infrastructure scanning. |
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.
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.
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:
scan_compliance_hipaa.* artifacts.
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.
| Category | Vendor | Wedge | NSAuditor differentiation |
|---|---|---|---|
| HIPAA-focused GRC | Compliancy Group, Drata HIPAA, Vanta HIPAA, Tugboat Logic | Workforce-training tracking, BAA management, policy templates, risk-analysis workflow | NSAuditor produces the §164.312 Technical Safeguards substrate evidence the GRC platform cannot. Complement, not replacement. |
| Legacy security scanners | Tenable, Qualys, Rapid7 | CVE detection at scale | NSAuditor produces §164.312-mapped evidence (the format auditors actually want) rather than raw CVE lists. |
| HIPAA consulting firms | KirkpatrickPrice, Coalfire, A-LIGN | Audit + advisory services | NSAuditor produces the pre-audit gap report the consultant builds the audit on top of — reduces consultant billable hours. |
| AWS-native HIPAA | AWS Audit Manager (HIPAA framework) | Pre-built control assessments using AWS Config | AWS Audit Manager covers AWS-only; NSAuditor adds Azure + GCP + on-prem scanning + cross-cloud bucket dedup + GRC platform push + WORM evidence storage. AWS Audit Manager doesn't produce institutional-grade evidence artifacts (no chain-of-custody envelope, no cover-page scope attestation). |
No. Zero Data Exfiltration architecture means ePHI never leaves customer infrastructure. No BAA needed — Nsasoft is not a Business Associate under §160.103.
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.
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.
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".
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.
No. BAAs are legal documents managed in contract-lifecycle systems (e.g., GRC platforms, contract-management software).
§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.
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.