Incident Response and Breach Notification Policy

This Incident Response and Breach Notification Policy describes how Pivot Technologies Holdings Inc. (“Pivot”) detects, investigates, contains, remediates, and communicates about security incidents and personal data breaches affecting Pivot’s Services and Websites. It also explains how Pivot notifies Customers and, where Pivot is legally responsible, regulators and affected individuals. This policy is designed to align with widely used incident handling lifecycle practices (preparation; detection/analysis; containment/eradication/recovery; post-incident improvements).

Table of Contents

1. Purpose
2. Scope
3. Key Definitions
4. Roles and Responsibilities
5. Incident Intake and Triage
6. Incident Severity and Classification
7. Incident Handling Process
8. Evidence Preservation and Logging
9. Customer Notifications
10. Breach Notifications (Regulators and Individuals)
11. Communications and Public Statements
12. Post-Incident Review and Corrective Actions
13. Testing, Training, and Maintenance
14. Exceptions
15. Changes

1. Purpose

Pivot maintains an incident response program to:

• Protect the confidentiality, integrity, and availability of Pivot systems and data.
• Restore secure operations quickly after disruptive events.
• Provide timely and accurate communications to Customers and other stakeholders.
• Meet contractual and legal obligations related to security incidents and personal data breaches.

2. Scope

This policy applies to:

• Pivot production systems, infrastructure, and internal tools used to operate the Services and Websites.
• Security incidents affecting Customer Data processed by Pivot on behalf of Customers.
• Security incidents affecting Pivot-controlled data (e.g., account, billing, and Website analytics data) where Pivot acts as a controller, consistent with Pivot’s Privacy Policy.

This policy does not replace Customer responsibilities for their own security controls, configurations, or incident response processes within their organizations.

3. Key Definitions

• Security Incident (Incident): An event that could compromise the confidentiality, integrity, or availability of Pivot systems or data (e.g., unauthorized access attempts, malware, service disruption, data exfiltration indicators).
• Personal Data Breach: A breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.
• Customer Data: Data that Customers and their Authorized Users submit to the Services (as defined in Pivot’s Privacy Policy / DPA context).
• Pivot-Controlled Data: Data Pivot processes as a controller (e.g., certain Website and account administration data), as described in the Privacy Policy.
• Customer: The entity that enters into an agreement with Pivot for use of the Services.
• Awareness: The point in time when Pivot has a reasonable basis to conclude a Security Incident or Personal Data Breach may have occurred and begins formal investigation (triage).

4. Roles and Responsibilities

Pivot assigns incident response responsibilities to ensure clear ownership, fast decisions, and controlled communications:

• Incident Commander (IC): Coordinates the response, sets priorities, runs incident meetings, and approves containment actions.
• Security Lead: Leads technical investigation, determines likely scope/impact, oversees evidence handling, and recommends remediation.
• Engineering Lead / On-Call: Implements containment, mitigation, and recovery steps; validates production changes.
• Legal and Privacy: Advises on regulatory and contractual obligations, breach assessment, and notification requirements.
• Customer Support / Success: Coordinates Customer communications and inbound questions using approved messaging.
• Executive Approver (as needed): Approves high-impact decisions (e.g., broad credential resets, emergency maintenance, public statements).

5. Incident Intake and Triage

Pivot may learn about potential incidents from multiple sources, including:

• Automated monitoring and alerting (availability, authentication anomalies, suspicious traffic, integrity checks).
• Internal reports from staff or contractors.
• Customer or third-party notifications.
• Vulnerability reports (including responsible disclosure).

All reports are triaged to determine:

• Whether an incident is plausible.
• Whether immediate containment is required.
• Which systems and data types might be affected.
• Whether the event may qualify as a Personal Data Breach.

6. Incident Severity and Classification

Pivot classifies incidents to drive escalation speed and communication rigor. A typical severity model includes:

• SEV-1 (Critical): Confirmed active compromise, likely data exposure, widespread outage, or significant safety/legal risk.
• SEV-2 (High): Suspected compromise with credible indicators, limited service impact, or potential exposure under investigation.
• SEV-3 (Medium): Contained security event with limited impact (e.g., blocked intrusion attempt requiring follow-up).
• SEV-4 (Low): Benign or informational security events, false positives, or low-risk issues.

Severity can change as new facts emerge.

7. Incident Handling Process

Pivot follows an incident handling lifecycle consistent with established guidance: preparation → detection/analysis → containment/eradication/recovery → post-incident activity.

7.1 Preparation

Pivot maintains security readiness measures, including:

• Access controls and least privilege.
• Production logging and alerting.
• Defined on-call escalation paths.
• Secure backup and recovery procedures (see “Data Backup, Retention, and Recovery Policy”).
• Runbooks for common incident types (credential compromise, suspicious logins, service degradation, etc.).

7.2 Detection and Analysis

Pivot investigates suspected incidents to establish:

• What happened: indicators, timeline, affected components.
• Scope: systems, accounts, organizations, or data categories potentially affected.
• Impact: availability, integrity, confidentiality, and whether personal data may be involved.
• Root cause hypotheses: vulnerabilities exploited, misconfigurations, credential compromise, third-party component issues.

7.3 Containment

Containment actions are taken to limit damage and prevent spread. Examples:

• Disabling affected accounts, tokens, keys, or integrations.
• Blocking malicious IPs or traffic patterns.
• Isolating services, scaling down risky components, or temporarily restricting features.
• Increasing monitoring and logging for affected systems.

Pivot prioritizes containment actions that reduce risk quickly while preserving evidence and minimizing disruption.

7.4 Eradication and Remediation

Pivot removes the threat and addresses underlying causes, which may include:

• Patching vulnerabilities and rotating credentials.
• Removing malware or unauthorized artifacts.
• Tightening access controls, rate limits, and detection rules.
• Fixing misconfigurations and strengthening change controls.

7.5 Recovery

Pivot restores normal operations and validates system integrity, including:

• Verifying services are functioning securely.
• Monitoring for recurrence.
• Restoring data or systems from backups if needed (where feasible and appropriate).

8. Evidence Preservation and Logging

Pivot preserves relevant evidence to support investigation and compliance:

• Security logs, access logs, audit trails, and relevant system telemetry.
• Incident timeline notes and actions taken.
• Forensic artifacts where applicable (snapshots, hashes, packet captures if available).

Access to incident evidence is restricted to authorized personnel. Pivot documents decisions and maintains internal records to support post-incident analysis and any required attestations.

9. Customer Notifications

When an incident may affect Customer Data, Pivot will notify the relevant Customer(s) without undue delay after confirming that Customer Data was accessed, disclosed, or reasonably believed to be at material risk, consistent with applicable agreements and the DPA.

Customer notifications typically include (as available and appropriate):

• A high-level description of what occurred.
• The approximate timeframe and affected services/components.
• The categories of Customer Data potentially involved.
• Containment/remediation steps taken by Pivot.
• Recommended Customer actions (e.g., reset credentials, review access logs).
• Ongoing investigation status and next update timing.

If an incident is still under investigation, Pivot may provide an initial notice with preliminary facts and follow up as findings are validated.

10. Breach Notifications (Regulators and Individuals)

Customer Data (Processor context).Where Pivot processes Customer Data as a processor, the Customer is typically the controller and is responsible for regulatory notifications and communications to individuals. Pivot will provide reasonable assistance and information needed for the Customer to meet its obligations, consistent with the DPA and applicable law.

Pivot-Controlled Data (Controller context).If Pivot determines a Personal Data Breach affects data for which Pivot is the controller, Pivot will assess notification obligations under applicable law and, where required, notify regulators and/or affected individuals. For example, under the GDPR, controllers must notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach (unless an exception applies).

Pivot’s breach assessment considers:

• Type and sensitivity of data involved.
• Likelihood and severity of risks to individuals.
• Whether data was encrypted or otherwise protected.
• Evidence of misuse or exfiltration.
• Whether the incident is ongoing.

11. Communications and Public Statements

Pivot controls external communications to reduce confusion and prevent accidental disclosure of sensitive details:

• Only designated roles (Legal/Privacy, Exec Approver, and authorized comms owners) may approve public statements.
• Customer-facing communications are coordinated to ensure consistency.
• Pivot avoids sharing exploit details that could increase risk, while still providing Customers meaningful remediation guidance.

12. Post-Incident Review and Corrective Actions

After resolution (or stabilization for prolonged incidents), Pivot performs a post-incident review to document:

• Root cause and contributing factors.
• Timeline and key decisions.
• Effectiveness of detection, containment, and recovery.
• Corrective and preventive actions (CAPA), owners, and deadlines.
• Monitoring improvements and runbook updates.

13. Testing, Training, and Maintenance

Pivot maintains the incident response program through:

• On-call training and runbook upkeep.
• Tabletop exercises and scenario reviews.
• Periodic review of notification templates and contact lists.

This policy is reviewed at least annually and after major incidents.

14. Exceptions

Any exceptions require approval from appropriate stakeholders (Security Lead and Legal/Privacy) and must be documented with compensating controls.

15. Changes

Pivot may update this policy to reflect changes in the Services, laws, or security practices. The “Last updated” date will be revised when material changes are made.