nx_privacy_lib.nx

nx_privacy_lib.nx -- PRIVACY COMPLIANCE: GDPR / CCPA subject-request clocks and breach notification. The OneTrust-class category we had at zero. Two clocks decide almost all exposure here, and both are routinely started from the wrong event. u2605THE 72-HOUR CLOCK RUNS FROM AWARENESS, NOT FROM THE BREACH (GDPR Art 33(1)). A controller that discovers on day 30 an intrusion that began on day 1 has 72 hours from DAY 30. Teams anchor to the incident date, conclude they are already hopelessly late, and then delay further -- or anchor to the forensic-conclusion date and report far too late. Awareness is the anchor; the incident date is evidence, not a deadline input. u2605AN EXTENSION MUST BE CLAIMED INSIDE THE ORIGINAL WINDOW. GDPR Art 12(3) allows a two-month extension on a subject access request, and CCPA allows a further 45 days -- but only if the data subject is informed WITHIN the original period. Notice given on day 31 of a 30-day window does not buy 60 more days; it is simply a late response. Encoded so a late claim can never extend anything. u2605ENCRYPTION IS A DEFENCE TO SUBJECT NOTIFICATION, NOT TO REGULATOR NOTIFICATION (Art 34(3)(a) vs Art 33). Rendering the data unintelligible excuses telling the individuals; it does NOT excuse telling the supervisory authority. Conflating the two is a real and expensive error, so they are separate. All periods are DATA (rule 11). Time is in HOURS for the breach clock and DAYS for request clocks -- deliberately different units because the statutes use different units, and silently converting is how 72 hours becomes "3 business days". STRUCTURE: pure decision core, zero I/O. license_tier: ORIGINAL LIB.