PII Incident and Breach Management Policy

The PII Incident and Breach Management Policy defines how an organization identifies, reports, triages, assesses, contains, notifies, documents, closes, and improves from PII incidents and PII breaches within the Privacy Information Management System scope. Its stated purpose is to ensure that incidents and breaches are handled consistently, promptly, lawfully, securely, and with audit-ready evidence. The policy applies across controller, joint controller, processor, and subprocessor contexts, and extends to systems, applications, services, processes, suppliers, processors, subprocessors, and third parties that process, store, transmit, support, access, or otherwise affect PII within the PIMS scope. A central feature of the policy is its integrated evidence model. REG10 — PII Incident and Breach Register is the primary evidence object for incident and breach management, while supporting registers provide context and traceability. REG01 supports scope, legal, contractual, sectoral, customer, and reporting context. REG02 links affected processing activities, PII categories, PII principal categories, purposes, and systems. REG04 supports privacy risk, DPIA, and residual risk linkage. REG08 records processor, subprocessor, customer, supplier, and third-party incident interfaces. REG09 is used when incidents affect cross-border processing, REG11 supports training and competence evidence, and REG12 captures audit, nonconformity, corrective action, and improvement evidence. This structure helps ensure incident records are not isolated from the wider PIMS. The policy sets detailed requirements for readiness, intake, classification, breach assessment, containment, recovery, notification, communications, evidence protection, and lessons learned. Suspected PII incidents must be recorded promptly, with every reported or detected suspected incident entered into REG10 within one business day of receipt, or sooner where notification or customer reporting timelines may be triggered. Technical triage of security events involving PII must be completed within 24 hours of detection, and each REG10 entry must be classified as a non-PII event, suspected PII incident, confirmed PII incident, or confirmed PII breach within 24 hours of intake unless the reason for pending classification is documented. For breach assessment, the policy requires identification of affected processing activities, PII categories, PII principal categories, systems, processors, subprocessors, transfer locations, and privacy risks before finalizing notification decisions. Notification and communication obligations are separated by role. For controllers, the policy requires documented regulatory notification decisions for every confirmed PII breach without undue delay, with notification, no-notification rationale, or delay rationale retained in REG10. Where communication to affected PII principals is triggered, the policy requires the content, audience, timing, delivery method, and approval evidence to be recorded. For processors and subprocessors, the policy requires notification to affected controllers, customers, upstream processors, or approved contractual channels without undue delay and within applicable contractual deadlines. For high-impact PII incidents, it also requires evaluation of legal, sectoral, financial-sector, cybersecurity, contractual, customer, and service-recipient reporting triggers where applicable. Governance, measurement, and improvement are built into the process. The Privacy Lead / PIMS Manager owns the incident and breach management process and must ensure REG10 is maintained through closure. The Incident Response Coordinator manages intake, triage, containment workflow, status tracking, closure, and lessons learned. Information Security leads technical investigation, containment, eradication, recovery, evidence preservation, and root-cause analysis where systems or security controls are involved. Top Management receives escalation for confirmed high-impact PII incidents within 24 hours of classification and reviews high-impact incidents, reportable breaches, overdue corrective actions, and material impacts during management review. Metrics include incident volumes, classification and containment timing, notification timeliness, corrective action aging, third-party response performance, and exercise completion. The policy also requires annual review, post-incident review after high-impact incidents or confirmed breaches, and annual internal audit review of implementation.