Internal Use

Responsible Disclosure Policy

Document Control

1. PURPOSE AND SCOPE

1.1 Purpose

This policy defines Dispel’s approach to responsible disclosure of security vulnerabilities and to whistleblowing related to information security policy violations, enabling safe reporting and coordinated remediation without retaliation.

1.2 Scope

This policy applies to:

• Dispel’s core platform, services, and information security infrastructure.
• External security researchers, customers, and other third parties who discover vulnerabilities.
• Internal personnel who report suspected security issues or policy violations.

1.3 Regulatory and Framework Alignment

2. POLICY STATEMENTS

2.1 Management Commitment

Management Commitment Statement

Senior Management at Dispel is dedicated to the protection of our information assets, industrial control systems, and Protected Health Information (PHI). We assume full accountability for the effectiveness of our security program, ensuring it is integrated into all business processes and aligned with our strategic goals. To maintain compliance with ISO 27001, IEC 62443, HIPAA, and NIST 800-53, we formally commit to:

• Resource Provisioning: Providing the necessary financial, technical, and human resources to sustain a robust security posture.
• Risk-Based Governance: Approving security policies and overseeing a continuous risk management process that prioritizes both data privacy and operational safety.
• Operational Resilience: Supporting the security of industrial automation and control systems (IACS) to ensure safety and reliability.
• Continuous Oversight: Conducting regular management reviews to evaluate program performance, audit results, and opportunities for improvement.

2.2 Primary Policy Statement

Dispel SHALL maintain a responsible disclosure program and whistleblowing channels that allow internal and external parties to report security concerns and policy violations safely, and SHALL address such reports in a timely and coordinated manner.

2.3 Secondary Policy Statements

At a minimum, Dispel SHALL:

• Document how to submit vulnerability reports and whistleblower reports.
• Define legal posture for good-faith security research within program scope.
• Define acceptance criteria for vulnerability submissions.
• Maintain a clear list of in-scope assets for reward eligibility.
• Prohibit retaliation against whistleblowers and reporters acting in good faith.

3. REQUIREMENTS

3.1 Legal Posture for Good-Faith Security Research

Dispel SHALL:

• Not pursue legal action against individuals who submit vulnerability reports through the designated channels and act in good faith within program scope.
• Accept testing of systems without harming Dispel or its customers, provided that:
  • Testing is within program scope.
  • No data is exfiltrated, destroyed, or misused.
  • Service availability is not deliberately degraded or denied.
• Require researchers to comply with applicable laws in their jurisdiction and Dispel’s jurisdiction.
• Require researchers to refrain from threats, extortion, or ransom demands.

3.2 Vulnerability Reporting Program

Dispel SHALL:

• Maintain a published contact (e.g., security@dispel.com) for vulnerability submissions to the Product Security team.
• Permit valid and in-scope reports to be eligible for discretionary payments.
• Require that submissions:
  • Demonstrate impact through proof-of-concept or clear description.
  • Avoid including unnecessary confidential data.
  • Not be publicly disclosed until a mutually agreed timeline has elapsed.

3.3 Preference, Prioritization, and Acceptance Criteria

Dispel SHALL prioritize and triage vulnerability reports based on:

• Clarity and quality of the report (well-written, with clear reproduction steps).
• Presence of proof-of-concept demonstrating exploitability.
• Impact on confidentiality, integrity, or availability of systems and data.
• Whether affected assets are within formally defined scope.

Researchers SHOULD:

• Provide detailed descriptions (how found, impact, potential remediation).
• Indicate any plans or intentions for public disclosure.

Dispel WILL:

• Acknowledge receipt within a defined timeframe (e.g., two business days).
• Communicate expected remediation timelines where feasible.
• Maintain an open dialog with the reporter.
• Notify the reporter when analysis and remediation are complete.
• Offer public credit after validation and fix, subject to mutual agreement.

3.4 Ineligible Vulnerabilities and Out-of-Scope Issues

Dispel SHALL maintain a list of vulnerability types and situations that are not eligible for reward (e.g., spam, version disclosure, clickjacking with no impact, missing best-practice headers, etc.), as further detailed in Appendix A.

3.5 Scope of Reward-Eligible Assets

Reward eligibility SHALL be limited to valid reports affecting assets in:

• *.dispel.com
• *.dispel.io

Other domains or systems MAY be reviewed and fixed, but may not be eligible for reward.

3.6 Program Terms and Conditions

Participants in the program MUST:

• Demonstrate exploitability without actually exploiting vulnerabilities (no unauthorized access, modification, or destruction of data).
• Use their own accounts where required, not interact with other users’ accounts or data.
• Avoid threats, extortion, or ransom related to discovered vulnerabilities.
• Comply with export control, sanctions, and eligibility rules (e.g., not be in embargoed jurisdictions or on restricted lists).
• Accept that bounty decisions and amounts are at Dispel’s sole discretion.
• Refrain from public disclosure without prior written approval from Dispel.

4. ROLES AND RESPONSIBILITIES

4.1 CEO or Delegate

• Owns and approves this Responsible Disclosure Policy.
• Reviews the policy at least annually and after significant changes.

4.2 Product Security / Security Team

• Triages incoming vulnerability reports.
• Coordinates with Engineering and Operations to validate and remediate vulnerabilities.
• Communicates with reporters and tracks issues to closure.

4.3 Legal / Compliance

• Advises on legal posture and program terms and conditions.
• Reviews whistleblower reports and ensures anti‑retaliation provisions are applied.

4.4 All Personnel

• Report suspected vulnerabilities and information security violations promptly.
• Use the designated channels for whistleblowing when necessary.

5. PROCEDURES

5.1 Vulnerability Reporting Procedure

1. Submission

   • Reporter sends a detailed report to security@dispel.com including description, impact, and proof-of-concept where feasible.

2. Acknowledgement

   • Product Security acknowledges receipt within the defined timeframe (e.g., two business days).

3. Triage and Assessment

   • Product Security evaluates scope, impact, and exploitability.
   • Valid reports are assigned a severity and owner for remediation.

4. Remediation and Verification

   • Engineering implements and tests fixes.
   • Product Security validates remediation before closure.

5. Closure and Credit

   • Issue is closed in the tracking system.
   • Reporter is notified and, where applicable, publicly credited.

5.2 Whistleblowing Procedure (Information Security Violations)

1. Submission

   • Reporter submits an anonymous or identified report of information security program violations to legal@dispel.io.

2. Evaluation

   • Executive team or designated Legal/Compliance members review the report.

3. Investigation

   • Investigators gather facts, preserving confidentiality to the extent possible while allowing proper due process.

4. Resolution

   • Verified violations lead to corrective actions and policy/procedure updates where needed.
   • Reporter is protected from retaliation; any retaliation discovered is subject to discipline.

Detailed acceptance criteria and ineligible vulnerabilities are documented in Appendix A.

6. MONITORING AND COMPLIANCE

6.1 Monitoring

Dispel SHALL monitor the effectiveness of this policy by:

• Reviewing vulnerability submissions and response times.
• Tracking resolution of valid findings.
• Monitoring the use and outcomes of whistleblower channels.

6.2 Non-Compliance

Non-compliance with this policy, including retaliation against whistleblowers or abuse of the responsible disclosure program, may result in disciplinary action up to and including termination, consistent with HR policies and applicable law.

7. EXCEPTIONS AND WAIVERS

Exceptions to this policy MUST:

1. Be documented and justified.
2. Be approved by Executive Management.
3. Be time‑bound and reviewed regularly.

8. DEFINITIONS

Responsible Disclosure: The process of reporting a security vulnerability to an organization in a manner that allows time for remediation before public disclosure.

Whistleblower: An employee or other individual who reports suspected violations of law, policy, or ethical standards.

Good-Faith Security Research: Security testing performed within authorized scope, aimed at improving security, without intent to cause harm.

9. REFERENCES

• SOC 2 Trust Services Criteria (CC7.x)
• ISO/IEC 27001 clauses 5.x
• NIST SP 800‑53 (IR-4, IR-6)
• IEC 62443 SR6.1
• HIPAA Security Rule 45 CFR §164.308(a)(6)
• OSHA 3905 Recommended Practices for Anti‑Retaliation Programs (for whistleblower context)

10. DOCUMENT HISTORY

11. APPROVAL SIGNATURES

END OF POLICY

APPENDICES

Appendix A: Ineligible Vulnerabilities and Out-of-Scope Issues

The following types of findings are generally not eligible for reward under this program (non‑exhaustive):

• Account squatting or preventing registrations with certain email addresses.
• Attacks requiring MITM or physical access to a user’s device.
• Best‑practice deviations without a concrete exploit (e.g., “weak” but acceptable TLS ciphers).
• Clickjacking where no sensitive action is at risk.
• CSV injection without a demonstrated exploit.
• Denial of service.
• Disclosure of server or software version numbers.
• Hypothetical subdomain takeovers without evidence.
• Issues requiring unlikely user interaction.
• Missing best‑practice headers or email records (SPF/DKIM/DMARC) without exploit.
• Open redirects without demonstrated impact.
• Reports based solely on automated scanner output, without manual validation.
• Vulnerabilities affecting only outdated or unpatched browsers.
• Social engineering and spam.

(Additional exclusions may be defined over time and communicated in program documentation.)