Vulnerability Disclosure Policy

Version 2.2, October 23, 2026.

Datafalk Inc. takes the security of its services and of its customers' data seriously. If you believe you have found a vulnerability in one of our services, we want to hear about it. This policy explains how to report it, what you may test, and what we commit to in return.

Contact

Send your report to security@datafalk.com, in English or French.

This address is also published in the /.well-known/security.txt file of each of our domains (RFC 9116). We do not publish a PGP key yet: do not include personal data or any secret you obtained in your first message. If we need them, we will agree with you on a secure way to exchange them.

Scope

This policy covers the following services:

  • www.datafalk.com, the public website;
  • app.datafalk.com, the Datafalk platform;
  • atlas.datafalk.com, the public Atlas;
  • demo.datafalk.com, the product demo.

Third-party services we use (hosting, payment, e-mail, etc.) are out of scope. Report vulnerabilities in those services directly to their vendor.

What we ask of you

To keep your research within this policy:

  • test only with your own accounts, or with accounts whose holder has explicitly allowed you to;
  • access, modify or delete other people's data only as far as strictly needed to demonstrate the vulnerability; stop as soon as you have, and delete that data once your report is sent;
  • do not degrade the availability of our services;
  • give us a reasonable time to fix the issue before any public disclosure (see below);
  • do not ask for anything in exchange for not disclosing.

The following are not allowed:

  • denial-of-service attacks, load testing and high volumes of automated requests;
  • social engineering (phishing, impersonation) targeting our employees, customers or partners;
  • attempts to gain physical access to our premises or those of our hosting providers;
  • sending spam or malicious content through our forms;
  • installing a backdoor or any persistent means of access.

What to include in a report

A good report lets us reproduce the issue quickly. Where possible, include:

  • the service and the URL or API endpoint involved;
  • the type of vulnerability and its impact as you see it;
  • the steps to reproduce it, with any useful requests, screenshots or proof of concept;
  • the date of your discovery, and the name or handle you would like to be credited under, if any.

Reports we usually do not accept

Unless you show a concrete security impact, we do not treat the following as vulnerabilities:

  • a missing security header or cookie attribute, on its own;
  • output from an automated scanner without a demonstration;
  • clickjacking on pages with no sensitive action;
  • disclosure of software version numbers;
  • account enumeration with no further consequence;
  • vulnerabilities that require an already compromised device or an outdated browser.

Our commitments

When you report a vulnerability in good faith, we commit to:

  • acknowledge your report within 3 business days;
  • send you our initial assessment within 10 business days;
  • keep you informed of progress on the fix;
  • let you know when the vulnerability is fixed;
  • credit you publicly, if you wish, once the fix is released.

We do not run a paid bug bounty programme.

Coordinated disclosure

We aim to fix confirmed vulnerabilities within 90 days of the report. Please do not disclose the vulnerability publicly before it is fixed or before that period ends. If a fix needs more time, we will explain why and agree on a new date with you.

Safe harbor

If you follow this policy, we consider your research authorised. We will not take legal action or file a complaint against you for that research. If a third party takes action against you for activities that comply with this policy, we will make it known that you acted within it.

This protection does not extend to activities that break applicable law or to the prohibited practices above. If you are unsure about a testing method, write to us before using it.

Changes to this policy

We may update this policy. The version in force is always the one published on this page, with its number and date.