IBCSC Institut belge de
cybersécurité citoyenne
EN
Support
Research carefully · report securely

A vulnerability needs a clear channel, not silence.

IBCSC authorises good-faith security research within the scope explicitly stated below. This policy explains what may be checked, what must remain untouched and how to coordinate a fix without exposing users.

Report a vulnerability Check the scope
Version 1.0 25 July 2026
Limited authorisationOnly listed assets and actions that are necessary, proportionate and non-destructive.
Direct channelAn identifiable contact with a CVD subject line, separate from the general incident form.
Stated follow-upAcknowledgement, triage, remediation and closure with communication objectives.
No bountyThis policy is not a bug bounty and promises no financial reward.

Narrow, written and conditional authorisation.

IBCSC authorises low-impact security testing on ibcsc.be when it is conducted in good faith, within the scope below and in strict compliance with this policy. Authorisation ends as soon as a condition is no longer met. It never covers third-party data, accounts, devices or services.

The scope is explicit.

A visible domain does not imply general permission. If an asset is not listed as open, ask for confirmation before taking any action.

ibcsc.be

Public website, pages, forms and web interfaces served directly by IBCSC.

Open

Low-rate manual or automated testing, with no third-party account, alteration or effect on availability.

Other assets

Unlisted subdomains, IP addresses, local networks, devices, social accounts and provider services.

Out of scope

No authorisation. Contact the relevant owner or request written confirmation from IBCSC.

Always out of scope

  • Data and accounts belonging to another user
  • Members’ workstations, phones and personal accounts
  • Suppliers, hosting providers, registrars and services reached through an external link
  • Buildings, physical access, people and social engineering
  • Networks or IP addresses not explicitly assigned on this page
  • Any activity prohibited by applicable law

Demonstrate the risk without creating another incident.

The demonstration must stop as soon as the issue can reasonably be established. Minimal proof is more useful than full exploitation.

What you may do

  • View and manipulate only your own data and test accounts
  • Use manual requests or a low-rate scanner
  • Check a hypothesis with the fewest requests necessary
  • Keep redacted screenshots and useful timestamps
  • Test input validation with a harmless payload
  • Report an access-control issue without opening third-party content
  • Request written confirmation when scope is ambiguous

What remains prohibited

  • Denial of service, load testing or resource exhaustion
  • Brute force, credential stuffing or repeated bypass of a limit
  • Phishing, pretexting, deceptive calls or other social engineering
  • Accessing, copying, changing or deleting third-party data
  • Installing malware, persistence, a backdoor or remote command facility
  • Pivoting, lateral movement or exploration of an internal network
  • Bulk email, spam or testing email accounts
  • Publishing a secret or exploitable detail before coordination
  • Degrading logs, evidence, backups or security controls

Stop rule: if personal data, a secret, a third-party session or unexpected access appears, stop immediately, do not explore further and report only the minimum necessary.

Send a concise, actionable report.

Use email for initial contact and place [CVD] in the subject line. Do not attach a dump, password, private key or dataset. If a sensitive transfer is genuinely necessary, IBCSC will propose a suitable channel after acknowledgement.

Security contact info@ibcsc.be

The return address may be pseudonymous, but it must allow coordination while the report is handled.

Machine-readable contact /.well-known/security.txt

The report should include

  1. 01

    The affected asset and exact URL

  2. 02

    A summary of the expected and observed behaviour

  3. 03

    The minimum steps required to reproduce the issue

  4. 04

    The plausible impact on confidentiality, integrity or availability

  5. 05

    Date, time, browser and environment used

  6. 06

    Redacted evidence containing no secret or third-party data

  7. 07

    Your preference regarding follow-up, public credit or anonymity

The report follows a chain of responsibility.

Each stage produces a clear status. A vulnerability should not disappear into an inbox, and a fix is not announced before verification.

  1. 01

    Receipt

    The report is recorded, its scope checked and manifestly excessive material isolated.

  2. 02

    Triage

    IBCSC attempts proportionate reproduction and assesses the practical impact.

  3. 03

    Immediate measure

    A temporary restriction may be applied when exploitation risk justifies prompt action.

  4. 04

    Remediation

    The fix is developed, tested, deployed and documented with relevant dependencies.

  5. 05

    Closure

    The reporter receives a final status and any publication is coordinated according to risk.

Communication objectives

These are service objectives, not a guarantee of remediation. Timing may vary with severity, dependencies and the association’s available capacity.

Human acknowledgement
5 working days
Initial triage
10 working days
Update while the case remains open
Every 15 working days
Expected coordination window
Up to 90 days

Priority follows verifiable impact.

Assessment considers exploitability, required privileges, reach, affected data and service consequences. An automated score does not replace context.

01

Critical

Direct, reproducible compromise of sensitive data, administration or an essential service.

Immediate action
02

High

Significant access, account takeover or material alteration under realistic conditions.

Priority handling
03

Moderate

Limited impact, multiple preconditions or an existing compensating control.

Prompt planning
04

Low

Reduced exposure, minor information or a defence-in-depth improvement.

Normal follow-up

A scanner signal is not always a vulnerability.

IBCSC reviews each good-faith report but asks for concrete and reproducible impact. This threshold reduces noise without dismissing a real risk.

Usually insufficient without demonstrated impact

  • A missing HTTP header with no exploitation scenario
  • A software version or banner with no applicable vulnerability
  • A raw automated report with no manual validation
  • Self-XSS requiring the victim to run the code themselves
  • Clickjacking on a page with no sensitive action
  • A configuration or encryption recommendation with no identified practical risk

A chain of several weaknesses may change the assessment. Explain the chain, but stop before accessing an unauthorised function or data.

Publication is a coordinated decision.

The first objective is to reduce risk to users. Confidentiality, credit and timing are discussed with the reporter, without an automatic promise of publication.

Confidentiality

IBCSC limits access to the report to people who need it to analyse, remediate or defend a right.

Publication

No exploitable detail should be published before written coordination. When the CCB legal procedure is used, its public-disclosure authorisation rules still apply.

Credit

Public acknowledgement may be offered after remediation, only with the reporter’s agreement and without revealing dangerous information.

Disagreement

If coordination becomes difficult, either party may ask the CCB to act as a trusted coordinator.

Retention

Reports and evidence are minimised, protected and retained according to security, evidential and site privacy requirements.

The Belgian CCB procedure remains available.

A person wishing to use the Belgian legal procedure must notify both the responsible organisation and the CCB, respect the necessity and proportionality conditions and follow the official deadlines.

  1. 24 hSimplified notification

    After reasonable discovery of a potential vulnerability, send the system identification and a simple description to the organisation and the CCB.

  2. 72 hComplete notification

    Complete the report to the organisation and the CCB in accordance with the procedure published by the CCB.

This page describes IBCSC’s internal policy and offers general guidance. It is not legal advice and does not replace the official CCB conditions, including those governing public disclosure.

Questions before you begin.

If scope or a method is uncertain, request written confirmation before testing.

May I use an automated scanner?

Yes on ibcsc.be at a low rate and without load testing, brute force or automated exploitation. A report must then be validated manually and explain the impact.

Does IBCSC pay a reward?

No. This policy is not a bug bounty and no remuneration is offered. Public recognition may be discussed after remediation.

May I publish after 90 days?

Not automatically. Timing must be coordinated in writing. If you use the Belgian legal procedure, the CCB conditions and authorisations for publication apply.

What if the vulnerability affects a third party?

Stop testing that party and contact its owner. The CCB may also act as a trusted coordinator when the correct recipient is difficult to identify.

A good report begins reducing risk in its first message.

Check the scope, retain minimal evidence and use the CVD channel. For an attack in progress or an affected person, use the official incident routes presented by the Observatory.