Regulatory Context¶

Every CDP includes a regulatory_context field that maps destruction steps to relevant regulatory provisions. This page explains what it is, what it isn't, and how to use it.

What It Is¶

The regulatory context is a factual reference mapping. It identifies which regulatory provisions are potentially related to the evidence generated by each destruction step.

For example, when the multi-pass memory overwrite (step 3) executes, the mapping notes that HIPAA §164.310(d)(2)(i) addresses device and media disposal, and that GDPR Article 17(1) addresses the right to erasure. These are factual statements about what those regulations say.

"regulatory_context": {
  "notice": "This mapping identifies regulatory provisions potentially related to the destruction evidence. It is not a compliance certification.",
  "framework_version": "2026-02",
  "mappings": [
    {
      "step": 3,
      "subsystem": "eee_memory",
      "frameworks": [
        {
          "regulation": "HIPAA",
          "provision": "§164.310(d)(2)(i)",
          "description": "Device and media controls — disposal",
          "relationship": "related_to"
        },
        {
          "regulation": "GDPR",
          "provision": "Article 17(1)",
          "description": "Right to erasure",
          "relationship": "related_to"
        },
        {
          "regulation": "SOC 2",
          "provision": "CC6.5",
          "description": "Logical and physical disposal of data",
          "relationship": "related_to"
        }
      ]
    }
  ]
}

What It Is NOT¶

Not a compliance certification

The regulatory context does not assert that your organization is compliant with any regulation. It does not replace a compliance audit, a legal review, or a DPO assessment. It is a reference mapping that helps your compliance team connect destruction evidence to the provisions they care about.

The relationship field is uniformly "related_to". You will never see "satisfies", "meets", "compliant", or "passed" in a regulatory context mapping. Nanorix maps evidence to provisions. Your compliance professionals determine whether the evidence satisfies their requirements.

How to Use It¶

For Auditors¶

When an auditor asks "how do you handle data disposal under HIPAA §164.310(d)(2)(i)?", you provide the CDP. The regulatory context mapping shows them exactly which destruction step relates to that provision, and the hash chain proves the step executed. The auditor verifies the CDP independently.

For DPOs¶

When processing a GDPR Article 17 erasure request, the CDP serves as evidence that data was destroyed. The regulatory context explicitly maps the destruction steps to Article 17(1). The DPO can include the CDP in their DSAR response documentation.

For Compliance Teams¶

The regulatory context saves the work of manually mapping destruction evidence to regulatory frameworks. Instead of a screenshot of a deletion log, your compliance team gets a cryptographically signed proof with framework references already attached.

Jurisdiction Filtering¶

The frameworks included in regulatory_context depend on the jurisdiction declared at signup:

Jurisdiction	Frameworks Included
`US`	HIPAA, SOC 2
`EU`	GDPR, SOC 2
`UK`	GDPR (UK), SOC 2
`CA`	PIPEDA, SOC 2
`AU`	Privacy Act, SOC 2
`OTHER`	SOC 2

All jurisdictions include SOC 2 mappings. Additional frameworks are jurisdiction-specific.

The jurisdiction is a customer declaration — Nanorix does not infer it from network signals or IP geolocation. You set it once at signup and it applies to all your CDPs.

Framework Versioning¶

The framework_version field (e.g., "2026-02") indicates which version of the regulatory provision mappings was used. If provisions are updated (e.g., a regulation is amended), the framework version will increment. Historical CDPs retain their original framework version.

Fields Reference¶

regulatory_context Object¶

Field	Type	Description
`notice`	string	Disclaimer stating this is not a compliance certification
`framework_version`	string	Version of the regulatory mapping (e.g., `"2026-02"`)
`mappings`	array	Array of step-to-framework mappings

Mapping Object¶

Field	Type	Description
`step`	integer	The chain step number (1-8) this mapping references
`subsystem`	string	The subsystem that generated the evidence
`frameworks`	array	Array of framework references for this step

Framework Reference Object¶

Field	Type	Description
`regulation`	string	Regulation name (e.g., `"HIPAA"`, `"GDPR"`, `"SOC 2"`)
`provision`	string	Specific provision reference (e.g., `"§164.310(d)(2)(i)"`, `"Article 17(1)"`)
`description`	string	Human-readable description of what the provision addresses
`relationship`	string	Always `"related_to"` — factual relationship, never evaluative

Comparison to GRC Platforms¶

Nanorix is not a replacement for OneTrust, DataGrail, Transcend, or other GRC platforms. Those platforms manage privacy workflows, consent, and data subject access requests. Nanorix provides the cryptographic evidence that data was actually destroyed — the verification layer those platforms lack.

Think of it this way: your GRC platform says "delete this record." Nanorix proves it was destroyed, with a signed, hash-chained proof that maps to the regulatory provisions your auditor cares about.