Vulnerability Disclosure Policy

Vulnerability Disclosure Policy

EXTERNAL --- CLEARED FOR CLIENT DISTRIBUTION

Safe Harbour, Scope, and Reporting Process for Security Research on ZINFI Unified Partner Management (UPM)

Prepared by ZINFI Technologies, Inc.

Created September 18, 2026

Executive Summary

ZINFI Technologies, Inc. welcomes reports of security vulnerabilities in the ZINFI Unified Partner Management (UPM) platform and in ZINFI-operated systems. This policy states what is in scope, what constitutes good-faith research, the safe harbour ZINFI extends to researchers who follow it, and how ZINFI responds.

• Researchers who act in good faith under this policy are not in violation of the ZINFI Acceptable Use Policy, and ZINFI will not pursue or support legal action against them.

• ZINFI acknowledges every report within three (3) business days and provides a triage determination within ten (10) business days.

• Remediation targets run from thirty (30) days for critical findings to best-effort for low-severity findings, with the researcher kept informed throughout.

• Coordinated disclosure is requested at ninety (90) days from acknowledgement, or earlier by mutual agreement once a fix is deployed.

• ZINFI does not currently operate a paid bug bounty. Recognition is offered, with the researcher's consent, in a public acknowledgements list.

1. Purpose and Commitment

ZINFI operates a multi-tenant Unified Partner Management (UPM) platform processing partner and personal data on behalf of its customers. Independent security research is a meaningful contribution to protecting that data, and ZINFI treats researchers who report responsibly as collaborators rather than adversaries.

This policy exists to remove the ambiguity that otherwise deters good-faith reporting. It states plainly what ZINFI permits, what it does not, and what a researcher can expect in return.

ZINFI's commitments to researchers: Acknowledge every report promptly. Communicate a triage decision and a remediation timeline. Keep the researcher informed of progress. Extend safe harbour to good-faith research under this policy. Offer public credit where the researcher wants it. Never pursue or support legal action against a researcher who follows this policy.

2. Scope

2.1 In Scope

• The ZINFI UPM production platform and its published APIs.

• ZINFI-operated web properties, including zinfi.com and the ZINFI Trust Center.

• ZINFI-published mobile and browser applications.

• ZINFI-operated authentication, session management, and tenancy isolation mechanisms.

• ZINFI-built connectors and integrations, where the defect lies in ZINFI's code.

2.2 Out of Scope

The following are outside this policy. Reports concerning them will be acknowledged but may not be actioned.

• Systems operated by ZINFI customers, including a customer's own deployment configuration, custom workflows, or content.

• Systems operated by third parties, including sub-processors, identity providers, and integrated CRM or ERP systems. Report these to the operator concerned.

• Findings requiring physical access to ZINFI premises or hardware.

• Social engineering, phishing, or pretexting directed at ZINFI personnel, customers, or partners.

• Denial-of-service and resource-exhaustion testing of any kind.

• Findings in third-party software for which no ZINFI-specific exploit path is demonstrated.

2.3 Findings ZINFI Does Not Consider Vulnerabilities

The following are frequently reported and are not treated as vulnerabilities absent a demonstrated security impact:

• Missing security headers with no demonstrated exploit.

• Output of automated scanners submitted without validation or a working proof of concept.

• Weaknesses in TLS configuration that do not enable a practical attack.

• Self-XSS, clickjacking on pages with no sensitive state-changing action, and missing cookie flags on non-session cookies.

• Username or email enumeration where disclosure presents no material risk.

• Rate limiting on non-authentication endpoints.

• Publicly disclosed software versions, absent a demonstrated exploit path.

3. Good-Faith Research and Safe Harbour

3.1 Rules of Engagement

Research qualifies as good faith under this policy where the researcher:

• Accesses, modifies, or exfiltrates no data belonging to any party other than themselves. Where a vulnerability exposes data, the researcher stops immediately upon confirming access and reports without retrieving further records.

• Causes no degradation, interruption, or destruction of service, and performs no denial-of-service testing.

• Uses only accounts they own or for which they hold explicit written authorization from the account holder.

• Does not pivot from a discovered vulnerability into further systems beyond what is necessary to demonstrate impact.

• Does not use social engineering, phishing, or physical intrusion.

• Reports promptly upon discovery and does not disclose publicly before the coordinated disclosure timeline in Section 5.

• Does not demand payment, threaten disclosure, or condition the report on compensation. A report made under such conditions is treated as an extortion attempt, not research.

• Complies with all applicable law and does not retain, sell, or transfer any data encountered.

3.2 Safe Harbour

Where a researcher acts in good faith in accordance with Section 3.1, ZINFI commits that:

• The research is authorized conduct and does not violate the ZINFI Acceptable Use Policy or the ZINFI Terms of Use.

• ZINFI will not initiate or support civil or criminal legal action against the researcher in connection with the research.

• ZINFI will not report the researcher to law enforcement in connection with the research.

• Where a third party initiates action against a researcher in connection with research conducted under this policy, ZINFI will make known that the research was authorized.

This safe harbour extends only to conduct within the scope of Section 2.1 and the rules in Section 3.1. It does not authorize access to customer data, to third-party systems, or to any activity unlawful independent of ZINFI's authorization. ZINFI cannot waive the rights of its customers or of third parties.

If you are unsure: Where a researcher is uncertain whether an intended test falls within scope or within the rules of engagement, ZINFI asks that they contact ZINFI before testing rather than after. ZINFI will respond with a scope determination and will not treat the enquiry itself as adverse.

4. Reporting a Vulnerability

4.1 How to Report

Submit reports through the security contact published in the ZINFI Trust Center. Vulnerability reports must not be submitted through general support channels, sales contacts, or social media, as those routes are not monitored for security-sensitive material and may expose the finding before it is remediated.

4.2 What to Include

• A clear description of the vulnerability and the security impact it enables.

• The affected system, URL, endpoint, or application component.

• Step-by-step reproduction instructions, with a proof of concept where practicable.

• The date, approximate time, and originating IP address of the testing.

• Any accounts used, so ZINFI can distinguish the research from malicious activity in its logs.

• Whether the researcher wishes to be publicly credited, and the name or handle to use.

Reports may be submitted anonymously. ZINFI will acknowledge and act on an anonymous report but cannot provide status updates or credit where no contact route is given.

4.3 Encryption

Researchers reporting a finding of high or critical severity are encouraged to encrypt their submission using the public key published alongside the security contact in the ZINFI Trust Center.

5. ZINFI's Response

5.1 Response Timeline

Acknowledgement: within 3 business days of receipt.

Triage determination (validity and severity): within 10 business days of acknowledgement.

Remediation plan communicated: within 15 business days of triage for confirmed findings.

Progress updates: at least every 15 business days until resolved.

Resolution notification: within 5 business days of deployment of the fix.

5.2 Remediation Targets

ZINFI assesses severity using the Common Vulnerability Scoring System, adjusted for the specific exploitability and data exposure presented in a multi-tenant environment.

Critical (cross-tenant data access, authentication bypass, remote code execution): 30 calendar days, with interim mitigation as soon as practicable.

High (privilege escalation within a tenant, significant data exposure): 60 calendar days.

Medium (limited data exposure, defects requiring unusual preconditions): 90 calendar days.

Low (minimal security impact, defence-in-depth improvements): best effort, typically the next scheduled release.

*Where a critical or high-severity finding affects customer data, ZINFI's incident response and breach notification obligations apply in addition to the remediation targets above.*

5.3 Duplicate and Known Findings

Where a report duplicates an existing finding or describes a defect already identified through ZINFI's own testing, ZINFI will say so at triage and will indicate the remediation status. Safe harbour under Section 3.2 applies to a duplicate report exactly as it does to a novel one.

6. Coordinated Disclosure

ZINFI asks that researchers withhold public disclosure until the earlier of (i) ninety (90) days from acknowledgement, or (ii) deployment of a fix, and that they coordinate the timing and content of any publication with ZINFI.

Where remediation requires longer than ninety days --- as is sometimes the case for architectural defects or findings dependent on a third-party fix --- ZINFI will explain why and propose a revised date rather than allow the deadline to pass silently.

ZINFI will not request indefinite non-disclosure, will not condition safe harbour on permanent silence, and will not require a researcher to sign a non-disclosure agreement as a precondition of reporting.

7. Recognition

ZINFI does not currently operate a paid bug bounty program. Where a researcher wishes to be credited, ZINFI will list their name or chosen handle in a public acknowledgements page following remediation, and will provide written confirmation of the finding and its resolution on request.

Recognition is offered only with the researcher's explicit consent. ZINFI will not name a researcher who prefers to remain anonymous.

8. Policy Administration

ZINFI reviews this policy at least annually and on any material change to the platform architecture or to ZINFI's security operations. Every version carries a version number and an effective date, and prior versions are retained and available on request.

Document version: This is Version 1.0 of the ZINFI Vulnerability Disclosure Policy, effective September 18, 2026. Owner: ZINFI Technologies Information Security. Next scheduled review: September 2027. Referenced by the ZINFI Acceptable Use Policy, Section 4.2.

Closing Summary

This policy gives security researchers what they need to report safely: a defined scope, explicit rules of engagement, a safe harbour commitment that ZINFI will not pursue legal action against good-faith research, a published response timeline from three-day acknowledgement through severity-based remediation targets, and a ninety-day coordinated disclosure window with no demand for permanent silence.

1. Review the scope in Section 2 before testing, and contact ZINFI where scope is unclear rather than proceeding on assumption.

1. Follow the rules of engagement in Section 3.1 --- safe harbour under Section 3.2 depends on them.

1. Submit reports through the security contact published in the ZINFI Trust Center, not through support or sales channels.

1. Include reproduction steps, the originating IP, and the accounts used, so ZINFI can distinguish research from malicious activity in its logs.

1. Indicate whether you wish to be publicly credited.

zinfi.com/trust-compliance-center

EXTERNAL --- CLEARED FOR CLIENT DISTRIBUTION