Security Disclosure Policy

1. Purpose

We want researchers, customers, leaders, and staff to tell us about security weaknesses privately so we can fix them before they are misused.

This policy explains:

• How to report a vulnerability or suspected incident.
• What is in scope and out of scope.
• How we will respond (severity and timeboxes).
• Safe-harbour conditions for good-faith research.
• How this sits with Australian NDB, APP 11, GDPR Articles 33–34, and marketplace confidentiality.

If you believe personal information has already been accessed or leaked, treat it as an incident (section 8), not only a bug report.

2. Contact

3. Scope

In scope

Good-faith reports that affect systems we own or operate:

• taackk.com and subdomains we control.
• Authenticated application surfaces (business onboarding, leader apply/profile, messaging, governance dashboards, billing portal we host).
• APIs, session handling, password reset, email verification, OTP, and role-based access (including Developer and staff roles).
• Account data isolation between businesses, between leaders, and between tenants.
• Misconfiguration of cookies, CORS, authorisation, or object-level access (IDOR-class descriptions, not exploit packs).
• Secrets accidentally exposed in public web assets, JS bundles, or repositories we control.
• Our use of Stripe, OpenAI, Google Analytics 4, and cloud hosts only insofar as our integration is wrong (for example, we logged a Stripe token in our app). Do not attack those vendors' core platforms.

Out of scope

We will not consider (and safe harbour does not cover):

• Denial of service, volumetric flooding, or physical attacks.
• Social engineering, phishing, or pretexting of Taackk staff, customers, or leaders.
• Spam, brute-force of credentials against production accounts that are not yours.
• Attacks on other customers' data or accounts, or using a finding to pivot into another tenant.
• Reports from automated scanners with no demonstrated security impact (missing headers alone, TLS grade nags).
• Clickjacking on pages with no sensitive action, logout CSRF, or similar low-impact issues without a realistic abuse path.
• Third-party products (Stripe, OpenAI, Google, Cloudflare email protection) except our misconfiguration.
• Attacks that violate Australian law, the Criminal Code, or equivalent computer-misuse laws.

No bounty programme is offered at this time. We may acknowledge you publicly if you want credit (section 10).

4. How to report

Send one email to [email protected] with:

• Title and affected URL or API route (no full exploit chain).
• Weakness class (for example: broken access control, session fixation, information disclosure).
• Impact in plain language — whose data or which action is at risk.
• High-level reproduction outline — enough for us to find the issue in our own environment. Do not attach working exploit code, malware, or payload packs.
• The date/time you noticed it, and whether you accessed anyone else's data (if yes, stop and tell us what was viewed).
• Your name or handle, and whether you want public credit.

If the report includes personal information, mark the email confidential. We prefer you use an account you own. Do not create fake engagements to harm other users.

5. Rules of engagement

To stay inside this policy you must:

• Stop testing as soon as you confirm a vulnerability.
• Avoid accessing, copying, or modifying data that is not yours. If you accidentally see it, note it, stop, and report.
• Not degrade the service (no DoS).
• Not demand payment as a condition of disclosure (extortion is referred to law enforcement).
• Give us a reasonable chance to fix before any public write-up (section 9).
• Comply with our Terms of Service acceptable-use rules — good-faith testing within this policy will not, on its own, be treated as a Terms breach.

We may suspend testing access if we believe research is harming the platform or other users.

6. Safe harbour

If you comply with this policy in good faith, Taackk will not bring a civil claim against you or refer you to law enforcement solely for that research.

Safe harbour does not apply if you:

• Access or exfiltrate other people's data beyond the minimum needed to prove a bug.
• Extort, publicly dump, or sell the finding.
• Attack out-of-scope systems or third parties.
• Commit other crimes (fraud, privacy breaches against individuals, etc.).

This is a statement of our intent, not a waiver of law we cannot waive, and not authorisation to attack systems we do not own.

7. Severity, SLAs, and workflow

We grade incoming reports using Critical → Info and P0–P4 so engineering work is ordered. These grades are internal risk labels, not a public CVSS promise.

Timeboxes start when the mailbox receives the report on a Sydney business day. P0 is treated as 24/7.

We will:

• Acknowledge receipt.
• Confirm whether the report is in scope and reproducible.
• Tell you when a fix is deployed (without giving you a new attack path).
• Ask you to retest only on accounts you own, if needed.

We may downgrade scanner-only reports with no demonstrated impact.

8. Suspected incidents and the NDB scheme

If you are a customer, leader, or staff member and you suspect unauthorised access:

• Email [email protected] immediately with timestamps, account email, and what you saw.
• Rotate your password and any API tokens you control.
• Do not email copies of other people's personal information more widely than needed.

Internally, Taackk will:

• Contain, investigate, and record the incident.
• Decide whether it is an eligible data breach under the Australian NDB scheme.
• Notify the OAIC and affected individuals when required.
• Where GDPR applies, assess 72-hour supervisory-authority notification.

9. Public disclosure and coordinated release

• Do not publish exploit details until we have mitigated the issue, or 90 days have passed, whichever is sooner — unless we agree another date (for example, a complex fix).
• We may request a delay if an active fix would put users at risk.
• We will not withhold a fix to avoid embarrassment.
• We may publish our own advisory (without reproducing attack steps) after mitigation.

If a researcher publishes prematurely in a way that harms users, safe harbour may not apply.

10. Recognition

There is no bug bounty at publication. With your permission we may list a handle on a "thanks" page after a validated, in-scope fix. We do not credit reports that are out of scope, duplicates, or that violated this policy.

11. What we will never ask you to do

We will not ask reporters (or staff following this policy) to:

• Write exploits, exploit PoCs, malware, or attack runbooks.
• Test using other customers' data.
• Bypass law-enforcement processes.
• Ignore NDB or GDPR notification duties.

Remediation advice we publish will be hardening and patching only.

12. Alignment with trust claims

Until SOC 2 / ISO 27001 reports exist:

• This disclosure programme is a control in progress, not a certificate.
• Marketing must not imply an independent audit that has not occurred.
• PCI DSS statements must stay limited to Stripe as processor — Taackk does not claim PCI certification.

13. Machine-readable disclosure file

The canonical RFC 9116 file is served at /.well-known/security.txt.

Contact: mailto:[email protected]
Contact: mailto:[email protected]
Encryption: https://taackk.com/pgp-key.asc
Expires: 2027-09-17T00:00:00.000Z
Preferred-Languages: en
Canonical: https://taackk.com/.well-known/security.txt
Policy: https://taackk.com/security
Acknowledgments: https://taackk.com/security#recognition
Hiring: https://taackk.com/careers

14. Internal owners

Review this policy at least annually and after every P0/P1 incident.

Controls in progress

The following controls have been identified and are at various stages of implementation. This list is updated as controls are resolved.