Skip to content

Security policy

How to report a security problem in Transport Chief, what we ask while you look, and what happens next.

Effective date: 8 September 2026

1. Purpose And Scope

Transport Chief Ltd (“we”, “us” or “our”) builds and operates the Transport Chief platform. We take the security of that platform, and of the information our customers trust us with, seriously. We welcome reports from security researchers, from our customers, and from anyone else who finds a problem.

This policy explains how to tell us about a security problem, what we ask of you while you are looking, and what you can expect from us in return. It is the policy referenced by our security.txt file.

This document is only about reporting security problems. How we collect and handle personal information is covered by our Privacy Policy, and the terms on which the platform is provided are in our Terms of Service.

2. Systems Covered

This policy covers the systems we run ourselves:

  • Our public website at www.transportchief.co.nz.
  • The Transport Chief application, and the customer facing booking pages we host on our customers’ behalf.
  • The public endpoints those services expose.

Services we use but do not operate, such as our hosting, email, DNS and bot protection providers, are outside this policy. Report a problem in one of those to the vendor concerned. If you are not sure whether something belongs to us, ask us at info@transportchief.co.nz before you test it.

3. How To Report A Vulnerability

Email info@transportchief.co.nz and put Security in the subject line, so your message reaches the right person quickly.

There is no web form and no ticket portal for security reports, and we would far rather have a plain email today than a perfectly formatted report next week. If a short description is all you have time for, send that.

We do not currently publish an encryption key. If you have something sensitive to send, email us first and we will agree a way to exchange it.

4. What To Include In A Report

A report we can reproduce is a report we can fix. Where you can, tell us:

  • The page, address or endpoint affected, and the date and time you tested.
  • What you did, step by step, and what happened.
  • Why you think it is a security problem, and what someone could do with it.
  • Any request or response detail, screenshots or a short video that helps us see it.
  • The account you were signed in as, if any, and the IP address you tested from.

Please send one report per issue, and say so plainly if you believe the problem is already being exploited.

5. What You Can Expect From Us

We are a small New Zealand team, so these are commitments we can actually keep:

  • We aim to acknowledge your report within five working days.
  • We will tell you whether we consider it a security issue, and roughly what we intend to do about it.
  • We will keep you posted while we work on it, and let you know when it is fixed.
  • We will not take legal action over a report made in good faith under this policy.

We treat your report as confidential. We will not pass your details to anyone outside our team without your permission, unless the law requires us to.

6. Testing Guidelines

While you are looking, please:

  • Use only your own accounts and your own test data.
  • Stop as soon as you have enough to demonstrate the problem, and go no further into a system than you need to.
  • Never access, change, download or delete anyone else’s data. If you come across someone’s personal information by accident, stop, and tell us in your report.
  • Do not degrade the service for anyone else. That rules out denial of service testing, load and stress testing, and automated scanning heavy enough to affect performance.
  • Do not use social engineering or phishing, and do not attempt anything physical, against our team, our customers or our suppliers.
  • Do not leave anything behind: no backdoors, no retained access, no test records in a live system.
  • Respect privacy and the law throughout.

If demonstrating something would require you to break one of these, contact us first and we will work out a safe way to do it together.

7. Usually Out Of Scope

The following are not usually accepted as security issues on their own. Send them anyway if you can show real impact, but expect us to close them if you cannot:

  • Missing security headers, cookie flags or preferred TLS settings, with no demonstrated exploit.
  • Output copied straight from an automated scanner, with no analysis and no proof of impact.
  • Problems that need a compromised device, a long outdated browser, or physical access to the victim’s machine.
  • Rate limiting, brute force or account enumeration claims with no working demonstration.
  • Email record configuration such as SPF, DKIM or DMARC, unless you can show a message actually being delivered as us.
  • Self inflicted issues, such as pasting a script into your own browser console.
  • Denial of service, and anything else that depends on volume rather than on a flaw.

8. Recognition And Rewards

We do not run a bug bounty programme and we do not pay for reports. We would rather say that here than leave you to find it out after the work is done.

What we can offer is a real answer, a fix, and public credit if you want it. Tell us in your report how you would like to be named, or that you would rather stay anonymous.

9. Coordinated Disclosure

Please give us a fair chance to fix a problem before you tell anyone else about it. Ninety days is the usual expectation, and most things take us a great deal less than that.

If you intend to publish, let us know so we can be ready, and please leave out any detail that would let someone reach an operator’s data before their system is patched. If we disagree about timing we will talk to you about it rather than go quiet.

10. Machine Readable Contact

Our security contact details are also published as a security.txt file, in the format described by RFC 9116. It names this page as our policy, and info@transportchief.co.nz as the address to write to. If the two ever disagree, the address on this page is the correct one.

11. Changes To This Policy

We may update this policy as the platform changes. The effective date at the top of the page tells you which version you are reading, and the current version always lives at this address.