Skip to content
CommsOperator
Request access

Responsible Disclosure Policy

Found a security bug in CommsOperator? Where to send it, what is in scope, what we ask you not to do, and what we promise back: a reply in 2 business days and no legal action for good-faith research.

Version
1.0
Effective
2026-08-26
Last updated
2026-08-26
Provider
WomenTech LLC
In short: found a security bug? Email office@commsoperator.com. We acknowledge within 2 business days, assess within 5, update you every 10, fix critical issues as fast as safely possible, credit you if you want, and take no legal action against good-faith research. There is no paid bounty. In short boxes are a plain-language guide. If a summary and the full text differ, the full text applies.

We welcome reports from security researchers. Send them to office@commsoperator.com. The same address is published in /.well-known/security.txt. We do not run a paid bug bounty programme; we do acknowledge researchers publicly with their permission.

In scope

In short: the application, the website, the widgets, the public API including the leads endpoint and the MCP server, and the desktop app and browser extension we distribute.
  • The application and website at https://www.commsoperator.com
  • The embeddable widgets and their public endpoints
  • The public API endpoints, including the leads endpoint and the MCP server
  • The desktop application and the browser extension distributed from our download page

Out of scope

In short: other companies' services, findings that need a compromised device, scanner output with no demonstrated impact, header and cipher nitpicks without an exploit, social engineering, and denial of service.
  • Third-party services we integrate with, such as Microsoft 365, OpenAI, or Stripe. Report those to their own programmes.
  • Findings that require a compromised device, a malicious browser extension, or physical access.
  • Reports produced only by an automated scanner without a demonstrated impact.
  • Missing security headers, weak TLS ciphers, or rate-limit findings without a working exploit path.
  • Social engineering of our team, our customers, or our providers.
  • Denial of service, volumetric testing, and spam.

Rules of engagement

In short: test only with your own account and data, stop if you reach someone else's, do not degrade the service, give us 90 days before publishing, and never ask for money to keep quiet.
  • Use only your own account and test data. Do not access, modify, or exfiltrate another customer's data; if you encounter it, stop and tell us.
  • Do not degrade the service for others. No load testing, no automated scanning at volume.
  • Give us reasonable time to fix an issue before publishing. We aim for 90 days and will tell you if we need longer and why.
  • Do not demand payment in exchange for withholding a report.

What to expect from us

In short: a reply in 2 business days, a severity call in 5, an update every 10, a fast fix for anything critical, credit on release if you want it, and no legal action for good-faith research.

How to read this table: each row is one step in our handling of your report and the time we aim to hit.

StepTarget
Acknowledgement of your report2 business days
Initial assessment and severity5 business days
Status update while we workEvery 10 business days
Fix for a critical issueAs fast as safely possible, usually days
Public credit, with your permissionOn release of the fix

If you follow this policy in good faith, we will not pursue legal action against you for your research, and we will say so in writing if a third party questions it.

Please include: what you found, where, a minimal reproduction, the impact you believe it has, and how you would like to be credited. Encrypted correspondence can be arranged on request.

Other documents