Responsible Disclosure Policy

Last updated 26 September 2026

Agencies trust Briesa with their trust-account records, the identity documents behind their AML checks and the compliance history an inspector reads. We welcome reports from anybody who finds a weakness in good faith, and would always rather hear about one than not.

Purpose

This policy says which of Briesa's systems you may test, how to tell us what you found, and what we undertake in return. It is written for security researchers acting in good faith, and for anybody else who stumbles on something that looks wrong.

Scope of systems

This policy covers the systems Briesa Pty Ltd operates:

  • briesa.com, the public site;
  • auth.briesa.com, the sign-in screens;
  • each agency's workspace at yourname.briesa.com, and the API it answers under /api/v1;
  • agency.briesa.com, the demo.

It does not cover the services Briesa relies on, which are listed on our Subprocessors page. Report a weakness in one of them to its own provider.

What we want to hear about

Anything that lets somebody do or see what they should not. Above all, anything that lets one organisation read or change another's records: every query Briesa runs is scoped to an organisation and the database enforces the same boundary again, so a way across it is the report we most want. Also:

  • a way to take over, or stay in, a session that is not yours;
  • a way past a second factor, a recovery code or a revoked API key;
  • injection, cross-site scripting or request forgery with a real effect;
  • a webhook or other outbound request that can be pointed inside a network;
  • a way to change or remove an audit-log entry or a compliance record.

Out of scope

These are excluded, at our discretion, unless they come with a working proof that they matter:

  • reports from automated scanners with no demonstrated impact;
  • missing headers, cookie flags or TLS settings with no practical attack;
  • denial of service, or testing that degrades the service for anybody else;
  • social engineering of our people or our customers, and physical attacks;
  • clickjacking on pages with no sensitive action;
  • anything that needs a compromised device or browser to begin with.

Rules for testing

  • Test against the demo where you can. It runs entirely in your own browser and never reaches the platform, so nothing you do there touches an agency's records.
  • Use only accounts you created. Never read, change or keep another organisation's data; if you reach some by accident, stop, and tell us what you saw.
  • Do not run anything that sends mail, SMS or payments to people who did not ask for it.
  • Give us a reasonable time to fix a problem before you tell anybody else about it.

How to submit a report

Write to support@briesa.com with a subject that starts with “Security”. Include what you found, where, the steps to reproduce it and what an attacker could do with it. Screenshots, requests and a short proof of concept help; the personal information of anybody but yourself does not.

What to expect

  • We acknowledge every report and tell you who is looking at it.
  • We keep you informed while we investigate, and tell you when it is fixed.
  • We credit you when it is fixed, if you would like to be.
  • We do not pursue anybody who follows this policy in good faith.

Changes to this policy

We may update this policy as the platform changes. The date at the top of this page says when it last did.

This is a template. The scope, the reporting address and the commitments here are placeholders. Review this policy with qualified legal and security advice before it is relied on. It does not constitute legal advice. All policies