Security and Vulnerability Disclosure Policy

Effective date: Pending confirmation
Last updated: 12 September 2026

Security is important to GTO Fisher. This Policy explains how users and security researchers can report a suspected vulnerability or incident while reducing risk to accounts, personal data and availability.

1. How to report

Email support@gtofisher.com with the subject “Security Report.” If ordinary email would expose an exploit, credential or personal data, first send a short message requesting a secure transfer method.

For an account compromise, include the account email, approximate time, affected device or session and a description of what you observed. Never email a password, authentication code or complete payment-card number.

For a vulnerability, include where possible:

• the affected hostname, page, feature, endpoint and version or environment;
• the vulnerability type and potential impact;
• clear, minimal reproduction steps;
• the date and time tested, IP address used for testing if you choose to provide it, and relevant request identifiers;
• sanitised screenshots, logs or proof of concept;
• whether any data was accessed, changed or exposed; and
• your preferred name and contact information, or state that you wish to remain anonymous.

One clear report is more useful than repeated automated submissions.

2. Current scope

This Policy covers systems under our control on gtofisher.com and its subdomains. A third-party checkout, email platform, content-delivery network or other provider may have its own disclosure programme. Report a provider-specific issue to that provider as well where appropriate.

Private-beta and test environments may contain experimental features but are not permission to access them without authorisation. An authentication or access-control page must not be bypassed merely because a hostname is discoverable.

3. Good-faith, low-impact research

We welcome reports based on research that is lawful, necessary to confirm the issue and designed to minimise harm. Reasonable examples include:

• inspecting public responses and client-side code;
• testing only an account and data you own or are expressly authorised to use;
• using a small number of manual requests to confirm an access-control, validation or configuration issue; and
• demonstrating impact with synthetic, redacted or minimally necessary data.

Stop testing and report immediately if you unexpectedly encounter another person’s data, a secret, administrative access, the ability to alter production data or a risk to availability. Do not continue to determine “how much” data is accessible.

This Policy is not a substitute for consent required by law and is not blanket authorisation to access our systems. We cannot authorise testing of third-party systems or promise immunity from action by another party.

4. Activities that are not permitted

Do not:

• access, copy, download, change, delete or disclose another user’s data;
• test with another person’s account, credentials or session without their express lawful authority;
• conduct denial-of-service, distributed denial-of-service, resource-exhaustion, flooding or load testing;
• use high-volume automated scanning, scraping, credential stuffing, password spraying or brute force;
• deploy malware, ransomware, a persistent agent, backdoor, web shell or destructive payload;
• perform social engineering, phishing, pretexting, spam or harassment of users, staff or providers;
• conduct physical intrusion, surveillance or testing of offices, personnel or devices;
• intercept communications or network traffic not intended for you;
• bypass payment, create fraudulent transactions, test stolen cards or trigger chargebacks;
• manipulate or destroy logs, scores, subscriptions, entitlements or production records;
• exploit an issue beyond the minimum necessary to show that it exists;
• retain sensitive data after reporting or transfer it through an insecure channel;
• threaten disclosure, outage or data release to demand payment or another benefit; or
• violate law, the Acceptable Use and Fair Play Policy or a third party’s terms.

Do not use a vulnerability to obtain poker strategy content, solver data, model information or paid access that you are not entitled to use. A content-access issue can normally be demonstrated with a redacted title, status code or minimal sample.

5. Handling accidental data access

If you inadvertently access personal, confidential or secret information:

1. stop immediately;
2. do not copy, search, enumerate, download or share it;
3. record only the minimum information needed to identify the issue;
4. notify us promptly and request a secure transfer method; and
5. securely delete any retained copy when we confirm it is no longer needed, unless law requires preservation.

In the report, describe the category and approximate amount without reproducing the data. Do not contact an affected user directly unless we or a competent authority asks you to do so.

6. Our response process

We aim to:

• acknowledge a credible report within 5 business days;
• triage severity and request necessary clarification;
• contain an urgent issue as appropriate;
• investigate, remediate and validate a fix based on risk; and
• tell the reporter when the issue is resolved or otherwise closed, subject to security and legal limits.

These are targets, not service-level guarantees. Complex issues, provider dependencies, duplicate reports, legal review or incomplete information may require more time. We may combine duplicate reports and generally recognise the first report that provides enough information to reproduce the issue.

We investigate suspected personal-data breaches and notify regulators or affected individuals where applicable law requires it, as described in the Privacy Policy.

7. Good-faith reporting and legal posture

If you act in good faith, stay within this Policy, avoid harm and promptly report an issue, we do not intend to initiate legal action solely because of that compliant research. If a third party brings an action and we conclude you materially complied, we may confirm that fact where lawful and appropriate.

This statement is a description of our present enforcement approach, not a contract, immunity, statutory safe harbour, waiver of rights, authorisation to violate law, or commitment binding a government or third party. It does not apply to extortion, data theft, privacy invasion, service disruption, persistent access, fraud, knowing law violations or conduct outside this Policy.

If you are unsure whether a proposed test is permitted, ask before performing it.

8. Confidentiality and coordinated disclosure

Please give us a reasonable opportunity to investigate and reduce risk before public disclosure. Do not publish exploit details, personal data, credentials or information that would make active exploitation substantially easier.

We will try to coordinate a disclosure date and accurate description with a good-faith reporter. We may ask for delay where users remain at risk or a provider fix is pending. We cannot require indefinite silence, but this Policy does not grant a right to disclose protected personal data, trade secrets or unlawful material.

Do not use our name, logo or communications to imply that we endorsed a report or statement unless we agree in writing.

9. Recognition and rewards

We do not currently operate a paid bug-bounty programme and do not promise payment, gifts, public credit or employment. Do not test on the assumption that a reward will be offered.

If we choose to recognise a report, the form and eligibility are entirely discretionary and will be agreed separately. We will not publish a reporter’s identity without permission, except where law requires disclosure.

10. End-user account safety

If you suspect unauthorised account access:

• change the password using a trusted device;
• revoke sessions you do not recognise, where the control is available;
• secure the associated email account;
• do not reuse the old password elsewhere; and
• contact us promptly with the subject “Account Security.”

We will never ask for your password or authentication code by email. A payment-card issue should also be reported to the card issuer or payment provider identified on the statement.

11. Changes to this Policy

We may update scope, contact or testing rules as the Service changes. Check the current version before new research. A change does not authorise conduct that was unlawful or harmful when performed.

12. Contact

Email: support@gtofisher.com
Suggested subjects: Security Report or Account Security

ASTRA LOGIC TECHNOLOGY PTE. LTD.
36 Robinson Road, #21-01, City House
Singapore 068877