NSAuditor AI Enterprise 0.9.0 Ships HIPAA Security Rule §164.312 Technical Safeguards as Second Compliance Framework Alongside SOC 2 — HHS-OCR Ransomware-Defense Substrate Lands in the Default Distribution

LAS VEGAS, NV — May 21, 2026 — Nsasoft US LLC today shipped NSAuditor AI Enterprise Edition v0.9.0 to npm — the first 0.9.x release and the HIPAA framework cycle. HIPAA Security Rule §164.312 Technical Safeguards now ships as the second supported compliance framework alongside SOC 2. It is the twenty-sixth consecutive trio-publish across EE 0.9.0 + CE 0.1.69 + agent-skill 0.1.36.

The institutional context: SOC 2 has been the foundational compliance framework in NSAuditor AI EE since 0.3.0. HIPAA was the most-requested next framework — for healthcare CISOs, HealthTech CTOs, and SOC 2 + HIPAA dual-audit consultants who increasingly see the two audits in the same engagement. Today closes the long-standing “planned” gap on the public roadmap.

Coverage shape — §164.312 only

NSAuditor AI EE explicitly maps to §164.312 Technical Safeguards only. §164.308 Administrative Safeguards (workforce training, sanction policies, BAAs, contingency planning, security incident procedures — 31 specs) and §164.310 Physical Safeguards (facility access, workstation security, device disposal — 12 specs) are architecturally out of scope for any infrastructure scanner. The cycle ships data/compliance/hipaa.json with 175 mappings:

• 7 covered: §164.312(a)(1) Access Control, (a)(2)(i) Unique User Identification, (a)(2)(iv) Encryption/Decryption, (b) Audit Controls, (d) Person or Entity Authentication, (e)(1) Transmission Security, (e)(2)(ii) Encryption (transmission).
• 3 partial: (c)(1) Integrity, (c)(2) Mechanism to Authenticate ePHI, (e)(2)(i) Integrity Controls (transit) — storage-substrate and TLS-substrate evidence; application-layer record-level checksumming OOS by design.
• 45 explicit OOS: 2 within-§164.312 (Emergency Access Procedure procedural; Automatic Logoff application-tier), 31 entire §164.308 Administrative, 12 entire §164.310 Physical — each with named architectural-limit reasons pointing operators to pair with HIPAA-focused GRC platforms (Drata HIPAA, Vanta HIPAA, Compliancy Group, Tugboat Logic) for §164.308 and facilities + endpoint-management + asset-disposal vendors for §164.310.

HHS discipline enforced per control

Per HHS, §164.312 specifications carry exactly one classification: Required (R) — MUST implement — or Addressable (A) — MUST assess; if reasonable, implement; if not, document why AND implement an equivalent alternative. Misrepresenting Addressable as Required (or vice versa) is overclaiming — auditors specifically test for this discipline. Schema-additive fields per control in data/compliance/hipaa.json surface the metadata explicitly:

• requiredOrAddressable: 'R' | 'A'
• standardOrSpec: 'standard' | 'implementation-specification'
• ruleText: <HHS rule text verbatim>

§164.312(c)(1) ransomware-defense substrate — the HHS-OCR 2024 enforcement 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:

Logically Air-Gapped Backup Vault cross-verification:

• KMS policy verifier — confirms ZERO source-account grants on the destination KMS key.
• KMS Grants verifier — confirms ZERO source-account grantees.
• KMS replicas verifier — confirms ZERO replicas in the source account (multi-region key sanity).
• KMS VPC-endpoint verifier — confirms network-layer isolation.

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) and is dual-mapped to 164.312(c)(2) for the integrity-verification dimension.

Per-framework SLA-citation map closes cross-framework citation leak

A new helper frameworkControlCitation(framework, slot) returns the appropriate per-framework citations. SOC 2 reports continue to cite CC7.1 remediation cadence (SLA), CC1.4 / CC8.1 (governance), and CC6.2 / CC6.3 (identity). HIPAA reports cite §164.312(b) audit-controls cadence (SLA), a §164.308 sentinel for governance (correctly noting governance is OOS in a §164.312 Technical-Safeguards report), and §164.312(d) Person or Entity Authentication (identity). HIPAA reports no longer leak SOC 2 control IDs — an auditor-detectable cross-framework citation defect closed in this cycle.

Dual-framework one-scan workflow

The engine was already framework-agnostic — loadFrameworkMap reads data/compliance/{framework}.json by parameter, schema-additive fields pass through transparently. The CLI parseFrameworks has accepted --compliance soc2,hipaa CSV since EE 0.3.0. The multi-framework workflow shipping today produces two evidence packs from one scan:

nsauditor-ai scan --host aws --plugins all \
  --compliance soc2,hipaa \
  --out evidence/

Output: separate scan_compliance_soc2.{md,html,json} AND scan_compliance_hipaa.{md,html,json} artifact sets, each with SHA-256 sidecars, RFC 3161 trusted timestamps, chain-of-custody envelopes, and scope attestations — same findings consumed by two framework engines.

Zero BAA required — the institutional differentiator

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 — 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. Complement, not replacement.

Quality gates

• +85 net new HIPAA-specific tests across 3 new test suites — 32 anchor-drift defense (inheritance contract from soc2.json), 36 engine-end-to-end mapping fixture tests, 17 renderer citation tests.
• 5,890/5,890 tests across 928 suites green. 69-session 100% green streak preserved.
• 2-agent parallel reviewer pass at end of cycle (HIPAA Security Officer perspective + senior code reviewer perspective) — zero R-CRITICAL findings; 6 reviewer folds applied same-session.
• AWS-dogfood verified against operator’s test AWS account: 207 findings analyzed, all routed to correct §164.312 sub-criteria; per-framework citation map confirmed firing in production reports; dual-framework run produced 21 artifacts in a single scan.

Install

npm install -g nsauditor-ai@0.1.69 @nsasoft/nsauditor-ai-ee@0.9.0
npm install nsauditor-ai-agent-skill@0.1.36

Coverage matrix: nsauditor.com/ai/docs/hipaa/. SOC 2 coverage matrix (unchanged): nsauditor.com/ai/docs/soc2/.

Read more about NSAuditor AI Enterprise Edition at nsauditor.com/ai/enterprise/.