Awareness Callout Policy

What this policy is

When we discover a security weakness in a third-party system (usually during our own legitimate use of that system, or through passive observation as part of broader market research) we will sometimes contact the operator of that system to share what we found.

This policy describes what we observe, what we do not do, how we contact you, the boundaries that govern this kind of outreach, and the Canadian legal context we operate within.

It is written for the recipient of a brief from us, so that if you ever receive one, you know exactly what it is and what it is not.

What we observe

Our observation is limited to information that any normal user of a service would encounter during ordinary use. This includes:

• HTTP responses to requests a typical user would make
• Public-facing pages, sitemaps, and metadata
• Information published in DNS records, certificate transparency logs, and other public sources
• The shape and behaviour of authentication flows we have legitimate access to (as a paying customer or invited guest)

This corresponds to the passive-testing methodology defined in NIST SP 800-115 section 4.1: non-invasive examination that does not interact with the target beyond a normal user session.

What we do not do

We do not:

• Attempt to exploit any vulnerability we observe beyond what is strictly necessary to characterise that it exists
• Enumerate, brute-force, or scrape data from systems we are not legitimately a customer of
• Bypass authentication, captchas, rate limiters, or other security controls
• Access, download, or retain data belonging to other users of any system we observe
• Use found-vulnerability information for any purpose other than private disclosure to the operator
• Publicly disclose specifics of a finding before the operator has had reasonable opportunity to remediate

How we contact you

If we observe something we believe is worth your attention, we will send you a private brief containing:

1. A clear description of what we observed: the finding
2. A characterisation of the risk it represents to you and to your users
3. Concrete, actionable remediation steps
4. A suggested timeline within which we recommend acting
5. Optional: an offer to discuss further or to help with remediation

Our brief format is rooted in ISO/IEC 29147:2018 (Information technology, Security techniques, Vulnerability disclosure). Briefs include structured findings, recommended remediations, citations to applicable standards (NIST SP 800-115, OWASP, CERT/CC CVD framework), and applicable Canadian compliance context (PIPEDA, BC PIPA, Alberta PIPA, Quebec Law 25 where relevant).

What this is not

This is not:

• A penetration test of your system (we are not engaged by you)
• A bug bounty submission (we are not seeking a reward)
• A demand for engagement (no obligation to respond, hire us, or take any action)
• A threat of public disclosure (we will not publish specifics of a finding without prior coordination with you)
• An attempt to access your customers’ data (we observe only what is exposed to a normal user session)

If you are unsure how to read a brief from us, this section is the answer: it is a courtesy notification, sent privately, that you are free to act on, ignore, or forward.

Coordinated disclosure pathway

If we send you a brief, our default disclosure pathway follows the CERT/CC Coordinated Vulnerability Disclosure (CVD) framework:

Day	Activity
Day 0	Private brief delivered to you
Day 7	Acknowledgement expected (we follow up if no reply)
Day 30	Reasonable fix deadline for the listed remediations
Day 60	Coordinated public disclosure timeline begins if no fix
Day 90	Public disclosure may occur: anonymised, no recipient-specific PII

This timeline is a default, not a deadline. We accommodate reasonable extensions and we work with you privately if you let us know what you need.

Recipients may also request that we omit public disclosure entirely if remediation is timely or if disclosure would harm users more than help them. We treat such requests in good faith on the facts of each case.

Canadian legal context

We operate under Canadian law. The Government of Canada has acknowledged that there is currently no statutory safe harbour for good-faith security research in Canada. We work within that constraint by:

• Using only passive methodology that does not require authorisation in the first place
• Relying on the common-law principle of “colour of right”: that our good-faith action does not constitute the fraudulent or unauthorised conduct prohibited by Criminal Code s.342.1
• Maintaining records of every observation so that if any question arises, the activities are fully documented and defensible
• Treating every finding as if it could be reviewed by a court, which informs our scope, our discipline, and the language in this policy

We acknowledge openly that this is a constraint, not a privilege we have been granted. The Rogers Cybersecure Catalyst report at Toronto Metropolitan University has called for federal reform of this gap; we support that work.

Compliance context for Canadian recipients

Our services aligned with PIPA and PIPEDA. See our Terms for the detailed compliance framework.

Who we serve

Vanwebdev LTD currently serves Canadian operators only. If you are outside Canada and receive a brief from us, it is because your platform serves Canadian users or stores data subject to Canadian privacy law. Recipients outside Canadian jurisdiction are welcome to act on the brief; we do not perform engagement work outside Canada at this time.

If you want to talk

If you receive a brief from us and want to ask a question, request clarification, or discuss the finding, use our contact page. Inquiries reach our team directly. We do not couple this policy to a commercial offer: the brief is yours regardless of whether any further engagement follows.

Limitations

Briefs we publish are based on information observed at a specific point in time, often constrained by the limits of passive observation. As such, the findings documented in any brief should not be considered a comprehensive list of security issues, flaws, or defects in the target system or codebase. We make no representations or warranties, express or implied, about the completeness, accuracy, or reliability of any brief beyond the specific findings explicitly stated within it.

This page is general legal information, not legal advice. Operators should consult their own counsel for advice specific to their situation.

Updates to this policy

We will update this policy as the Canadian legal landscape, international standards (ISO/IEC 29147, NIST SP 800-216, CERT/CC CVD), and our own methodology evolve. Material changes will be noted at the top of the page with the effective date.

Effective: 2026-05-18.
Last updated: 2026-05-18.