Incident Response & Breach Notification
Incident Response and Breach Notification
EXTERNAL --- CLEARED FOR CLIENT DISTRIBUTION
ZINFI's Commitments on Detection, Containment, Notification, and Post-Incident Reporting
Prepared by ZINFI Technologies, Inc.
Created September 18, 2026
Executive Summary
This document states what ZINFI Technologies, Inc. commits to do when a security incident affects the ZINFI Unified Partner Management (UPM) platform or the data it processes. It defines what counts as an incident, the notification windows ZINFI works to, what a notification will contain, and what ZINFI provides after the incident closes.
- Personal data breach notification to affected customers occurs without undue delay and in any event within seventy-two (72) hours of ZINFI confirming the breach.
- Security incidents that do not constitute a personal data breach are notified within five (5) business days of confirmation.
- Notification is not withheld pending complete investigation --- ZINFI notifies on confirmation with what is known, then supplements.
- A written post-incident report, including root cause and corrective actions, follows within thirty (30) days of incident closure.
- Sub-processor incidents affecting customer data are treated as ZINFI incidents, with the same notification obligations owed to the customer.
1. Scope and Definitions
1.1 Scope
This document applies to security incidents affecting the ZINFI Unified Partner Management (UPM) production platform, ZINFI-operated infrastructure, and personal data processed by ZINFI on behalf of its customers. It states ZINFI's commitments to customers. It is not the ZINFI internal incident response runbook, which is an internal operational document.
1.2 Definitions
- Security Incident --- any confirmed event that compromises, or is reasonably likely to have compromised, the confidentiality, integrity, or availability of the platform or of data processed within it.
- Personal Data Breach --- a Security Incident leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data, as that term is used in applicable data protection law.
- Confirmation --- the point at which ZINFI has established, on reasonable investigation, that a Security Incident has in fact occurred. An unverified alert, an anomaly under triage, or an unsubstantiated third-party claim is not a confirmation.
- Containment --- action taken to stop an incident progressing or recurring, whether or not the underlying defect is yet remediated.
1.3 What Is Not an Incident
The following do not trigger the notification commitments in Section 3:
- Unsuccessful attempts that ZINFI's controls blocked as designed, including failed authentication attempts, blocked scanning and probing, and rejected malicious payloads.
- Scheduled maintenance and planned unavailability conducted under the ZINFI Service Level Agreement.
- Vulnerabilities reported and remediated with no evidence of exploitation, which are handled under the ZINFI Vulnerability Disclosure Policy.
- Incidents confined to a customer's own systems, configuration, or credentials, where ZINFI's platform was not compromised. ZINFI will assist but the incident is the customer's.
2. Detection and Response Process
2.1 Lifecycle
Detect: automated monitoring, log analysis, alerting, researcher reports under the Vulnerability Disclosure Policy, customer reports, and sub-processor notifications.
Triage: validate the alert, establish whether an incident has occurred, assign severity, appoint an incident lead.
Contain: stop progression and prevent recurrence --- isolate affected components, revoke credentials, block attack paths.
Notify: commitments in Section 3 begin at confirmation, not at containment or resolution.
Eradicate and recover: remove the cause, restore affected services, verify integrity before returning to normal operation.
Post-incident review: root cause analysis, corrective actions, written report to affected customers.
2.2 Severity Classification
SEV-1 --- Critical: Confirmed unauthorised access to customer data, cross-tenant exposure, or complete platform compromise. Notification: within 72 hours of confirmation; affected customers notified individually.
SEV-2 --- High: Confirmed compromise of ZINFI systems without evidence of customer data access, or significant integrity impact. Notification: within 5 business days of confirmation.
SEV-3 --- Medium: Contained incident with no customer data exposure and no material service impact. Notification: summarised in periodic reporting; individual notification on request.
SEV-4 --- Low: Security event of note with no compromise and no customer impact. Notification: internal record only.
2.3 Containment Before Disclosure
Where notifying before containment would materially increase risk to customers --- for example by publicising an actively exploitable defect before a fix is deployed --- ZINFI may sequence a public statement after containment. This does not extend the individual notification windows in Section 3. Affected customers are notified within the stated windows regardless of whether a public statement has been issued.
3. Notification Commitments
3.1 Notification Windows
Personal Data Breach --- affected customers --- without undue delay, and in any event within 72 hours of confirmation.
Security Incident, no personal data breach --- affected customers --- within 5 business days of confirmation.
Sub-processor incident affecting customer data --- affected customers --- same windows, from ZINFI's confirmation of the sub-processor incident.
Post-incident report --- affected customers --- within 30 days of incident closure.
ZINFI does not wait for a complete picture: the seventy-two hour window runs from confirmation of the breach, not from completion of the investigation. ZINFI notifies within the window with the information available at that point and supplements as the investigation develops. Delaying notification until all facts are established would defeat the purpose of the window and is not ZINFI's practice.
3.2 Contents of a Notification
A notification under Section 3.1 will state, to the extent known at the time of issue:
- The nature of the incident, including the categories and approximate volume of data and records affected.
- The date or date range of the incident, and the date of confirmation.
- The likely consequences for the customer and for data subjects.
- Containment and remediation measures taken or in progress.
- Recommended actions for the customer, including any action required of the customer's own administrators.
- A named ZINFI contact for follow-up.
- Whether ZINFI has notified, or expects to notify, any supervisory authority.
Where information is not available at the time of notification, ZINFI will say so explicitly and will provide it in supplementary communications rather than omitting it silently.
3.3 How Notification Is Delivered
Notification is delivered to the security and legal notice contacts designated by the customer on its Subscription Order Form. Customers are responsible for keeping those contacts current. Where an incident affects platform availability, ZINFI will additionally use in-platform notification and the ZINFI status page.
3.4 Regulatory and Data Subject Notification
In the customer-ZINFI relationship, ZINFI acts as processor and the customer as controller. Notification to supervisory authorities and to affected data subjects is therefore the customer's decision and obligation. ZINFI's role is to provide, without undue delay, the information the customer reasonably requires to meet those obligations within its own regulatory deadlines. ZINFI will cooperate with any regulatory enquiry arising from an incident affecting customer data.
4. Post-Incident
4.1 Post-Incident Report
Within thirty (30) days of incident closure, ZINFI provides affected customers with a written report covering the incident timeline from detection to resolution, the root cause, the scope of data and systems affected, the containment and remediation actions taken, the corrective actions adopted to prevent recurrence, and the owner and target date for each corrective action not yet complete.
4.2 Corrective Actions
Corrective actions arising from a SEV-1 or SEV-2 incident are tracked to completion and reported to affected customers on closure. Where a corrective action requires longer than the original target date, ZINFI will notify affected customers with a revised date and the reason, rather than allow the date to pass without comment.
4.3 Customer Audit Rights
Customer audit and inspection rights following an incident are governed by the ZINFI Data Processing Addendum and the customer's Subscription Order Form. This document does not extend or limit those rights.
5. Related Commitments
The following ZINFI commitments operate alongside this document and are stated here so they can be located in one place:
Deletion of customer data within 30 days of a verified deletion request --- set out in the ZINFI AI and Partner Data Usage Policy and the Data Processing Addendum.
Purge of data from backups within 90 days --- set out in the ZINFI AI and Partner Data Usage Policy.
Sub-processor change notice --- set out in the Data Processing Addendum and the List of Sub-Processors.
Vulnerability reporting and researcher safe harbour --- set out in the Vulnerability Disclosure Policy.
Availability commitment and service credits --- set out in the Service Level Agreement.
5.1 Policy Administration
ZINFI reviews this document at least annually and after any SEV-1 incident. Where a change would lengthen a notification window or narrow a commitment, ZINFI will provide at least sixty (60) days' written notice and the change will not take effect for an existing customer until the start of that customer's next renewal term.
Document version: This is Version 1.0 of ZINFI Incident Response and Breach Notification, effective September 18, 2026. Owner: ZINFI Technologies Information Security and Legal. Next scheduled review: September 2027, or immediately following any SEV-1 incident.
Closing Summary
ZINFI commits to notifying affected customers of a personal data breach within seventy-two hours of confirming it, and of other security incidents within five business days. Notification is issued on confirmation with what is known and supplemented as investigation proceeds, rather than withheld pending a complete picture. A written post-incident report with root cause and corrective actions follows within thirty days of closure, and sub-processor incidents affecting customer data carry the same obligations as ZINFI's own.
- Confirm your security and legal notice contacts are current on your Subscription Order Form --- notification is delivered to those addresses.
- Establish internally who receives a ZINFI breach notification and who decides on regulatory and data subject notification, since those obligations sit with you as controller.
- Review the severity definitions in Section 2.2 so expectations align before an incident rather than during one.
- Note that incidents confined to your own systems, configuration, or credentials are outside this document --- ZINFI will assist, but the incident remains yours.
- Contact ZINFI through the Trust Center with any questions about notification contents, timing, or audit rights.
legal@zinfitech.com | zinfi.com/trust-compliance-center