...
- Generate new Law specific CR - based on Ext Specification by finding and replacing the terms in the spec. (have tested this and it works nicely)
Creating a template: using the template and providing instructions on using the template as notes, (in line )
Objective of this CR Extension
...
This extension to the Kantara CR V1.1 map's the [Law ] lexicon to the international ISO lexicon for explicit consent, while also adding extension fields to meet [Law e.g. HIPPA and CFR42a CFR42 Part 2] requirements.
This extension provides an example of how to generate an extension for the Kantara (Minimum Viable International) Consent Receipt v1.1 that maps a national legislation to and international standard, to enable cross domain interoperability in consent transparency internationally.
...
This specification extension acknowledges that an explicit consent receipt is made with a subset of fields in a consent record. This extension provides some guidance for keeping records of processing by defining the fields and format for creating a consent record that demonstrates compliance with {HIPPA & CFR42a} records
Wiki Markup |
---|
{CFR42 Part 2} |
records of processing and proof of notice for an explicit consent receipt to meet the requirements as set out in (list the reference) Regulation.
...
Records are required for explicit consent on behalf of the processor, this will be required if the Controller is audited, or if the controller is seeking accreditation for high assurance for explicit consent. In such context, these records should include the categories of recipients the nature and purpose of the processing, the type of PI and PI categories of PI Principles are required in the processor record for consent as defined in (list legal reference from HIPPAlaw e.g. CFR42 Part2)
For regulator and bodies providing codes of practices or accreditation, an explicit consent record requires the categories of recipients to whom the PI have been or will be disclosed, including recipients in third countries or international organisations; Including, the category of PI Principle – is required in a consent record along with the PI category, as required in records of processing that are used to produce a privacy notice or consent receipt.
Section 1: New and replacement terms in the extension
Section 2: fields mapped to the CR v1.1
Table 1
CR v1.1 Field Name | Equivalent GDPR Term | GDPR CR Field Name | GDPR Field Description (Put in examples) | JSON | Required / Optional | Data Type |
Version | ||||||
Jurisdiction | ||||||
Consent Timestamp | ||||||
Collection Method | ||||||
Consent Receipt ID | ||||||
Public Key | ||||||
Language | ||||||
PII Principal ID | ||||||
PII Controller | ||||||
On Behalf | ||||||
PII Controller Contact | ||||||
PII Controller Address | ||||||
PII Controller Email | ||||||
PII Controller Phone | ||||||
PII Controller URL | ||||||
Privacy Policy | ||||||
Service | ||||||
Purpose | ||||||
Purpose Categories | ||||||
Consent Type | ||||||
PII Categories | ||||||
Primary Purpose | ||||||
Termination | ||||||
Third Party Disclosure | ||||||
Third Party Name | ||||||
Sensitive PII | ||||||
Sensitive PII Category |
Section 3: Additional CR v1.1 Field Extensions for CFR42 Part2
Table 2:
Field Name | Guidance | Description | Data Types (define field format) | JSON | Required / Optional |
Section 4: Schema
Summary
Appendex
The specification.
Once the above is complete, find and replace the terms in the CR, Update the terminology and definitions with the above specified information tor produce a new law specific version of the CR v1.1 specification