SINCLIQBack to Sincliq

Legal information

Privacy PolicyWebsite TermsMerchant AgreementCookie PolicyReport IP InfringementReport a Vulnerability
Market
PolandGermanyUnited States
Language
PolskiDeutschEnglish

United States · Version 2026-10-08

Report a Vulnerability

Contact us about this

On this page

  1. Report a security concern
  2. Ordinary use and observation
  3. Permission before active testing
  4. Actions outside this policy
  5. Minimal, useful evidence
  6. Unexpected access to data
  7. Urgent incidents and safe contact
  8. Assessment and communication
  9. Remediation and retesting
  10. Coordinated disclosure
  11. Protecting reports and personal data
  12. US: data breach responsibilities
  13. Cooperation and recognition

1. Report a security concern

Report a suspected vulnerability or incident for the selected market to Sincliq Inc., 1000 Northwest Street, Mid-Town Brandy Wine, Suite 1200, Wilmington, DE 19801, USA, by emailing hello@sincliq.com with the subject “Security”. Start with a short account of the issue, affected service and potential consequences. Identify the country involved and your preferred reply language: Polish, German or English. Website language does not change the responsible entity. You do not need to demonstrate a successful attack or run another test to report a reasonable concern. This document explains safe reporting and cooperation; a report, automated acknowledgement or correspondence alone does not authorize system testing.

2. Ordinary use and observation

You may report an issue observed while lawfully browsing public pages, reading information normally delivered to your browser or using your own account within its granted permissions. Reproducing a vulnerability is not required. Public availability of an address, file or form is not open permission to test it. Changing identifiers to probe other people's data, attempting access-control bypasses, sending crafted requests and automated scanning go beyond ordinary observation. If further investigation would require those steps, stop and describe what you have already observed. The absence of a technical barrier does not expand your authorization.

3. Permission before active testing

Before active testing, obtain express written permission from an authorized representative specifying systems, methods, test accounts, dates and stop conditions. Send a proposed scope to hello@sincliq.com; submitting it or receiving no response does not mean approval. Permission for one test does not automatically cover other environments, features or later attempts. A venue customer's, employee's or account holder's consent may not authorize work on Sincliq infrastructure. Appropriate permission must exist from those controlling the affected resources. Resolve unclear ownership or scope before acting. This policy is not a general research authorization or a substitute for that agreement.

4. Actions outside this policy

Do not obtain, export or copy other people's data, or modify or delete data or configuration. Do not conduct load or denial-of-service testing, mass password guessing, use of stolen credentials, social engineering or physical intrusion. Do not establish persistent access, move across systems or initiate financial transactions to demonstrate impact. This policy does not cover testing customers, payment providers, cloud providers or other third parties, including through a Sincliq integration. Good intentions or a wish to confirm scale do not justify increasing harm. Any existing separate testing agreement remains governed by its own scope and conditions.

5. Minimal, useful evidence

Include the address or feature, date and time with time zone, software version, your own account's role, and expected versus observed behavior. Describe steps actually taken and potential impact, clearly distinguishing hypotheses from facts. A short redacted message extract or screenshot may suffice; a complete database export is not needed. Remove passwords, tokens, session cookies, keys, card numbers and customer information from text, images, addresses and metadata. Do not attach working exploit code or executable files to the first message. If evidence needs special protection, describe its nature and arrange an appropriate transfer method.

6. Unexpected access to data

If you accidentally encounter another person's data or a live secret, stop browsing and do not inspect additional records or check whether credentials work. Do not publish, circulate or use the information to sign in, contact affected individuals or establish the scale. Record only necessary details of location, time and the type of exposure without copying its contents. If a file downloaded automatically, secure it against further access and mention that fact; do not email it normally. Coordinate limited preservation or safe deletion subject to any legal duties. Do not modify or delete anything in the source system.

7. Urgent incidents and safe contact

For an ongoing exposure, account takeover or suspected active attack, email hello@sincliq.com with the subject “Security urgent”, identifying the service, time and immediate effects. Keep the first message to a non-sensitive summary without secrets. Any transfer of sensitive evidence must be separately agreed beforehand; making contact alone does not protect that information. This inbox does not guarantee round-the-clock coverage or an immediate response. For danger to life, contact emergency services; for threatened payments, also contact your payment provider through a verified route. You may secure your own account within your permissions. Do not intervene independently in someone else's systems.

8. Assessment and communication

Assessment considers credibility, actual effects on confidentiality, integrity and availability, exploitability, and the people and services involved. A technical severity score is not required; concrete consequences are more useful than a critical label alone. We may seek clarification of information already collected, which does not authorize another test. Reply in one thread and identify new circumstances. Privacy and an investigation may limit the details that can be shared. This policy sets no guaranteed acknowledgement, resolution or remediation time; statutory obligations apply independently. A lack of response does not expand the actions you are permitted to take.

9. Remediation and retesting

Suitable remediation depends on the cause, technical dependencies and the risks that changes pose to users. It may involve configuration changes, a fix, restricted functionality or revocation of exposed credentials by the responsible party. A message that a fix has been released is not an invitation to repeat an attack. Verification by the reporter requires separately agreed scope and permission, just like an initial active test. If you notice recurrence without further testing, report the new circumstances. A report may duplicate another or need clarification; this neither judges your motives nor permits risky methods to obtain stronger evidence.

10. Coordinated disclosure

Please allow reasonable time to assess and reduce risk before publishing details that enable exploitation. Share your proposed publication date and scope so a practical timetable and updates can be discussed. An extension should have a specific reason and a new review date; this policy creates neither an indefinite publication ban nor an obligation to wait endlessly for permission. If contact fails, consider an appropriate CERT or CSIRT for coordination. Do not publish personal information, secrets or instructions creating an immediate danger. Statutory reports to authorities, legally protected disclosures and access to legal advice remain available.

11. Protecting reports and personal data

Report information is used for handling the issue, protecting systems and people, necessary cooperation, and legal duties or claims. Access and sharing should be limited to information needed by those handling the matter, relevant providers, advisers or authorities on an appropriate basis. Absolute confidentiality or legal professional privilege is not promised. Reporting without a name may limit follow-up; a working return address ordinarily suffices without an identity document. Flag particular risks from revealing your identity. Retention follows the needs of the matter, obligations and claims. The privacy policy explains rights concerning personal information and how to exercise them.

12. US: data breach responsibilities

US breach duties depend on applicable state and sector laws, affected residents, data types and the entity's role. Incorporation in Delaware does not confine the assessment to Delaware law. Data owners or licensees and entities maintaining data may have different duties to notify each other, cooperate, and inform individuals or authorities. We assess these obligations against the incident; there is no single universal 72-hour deadline here. If GDPR also applies, its requirements must be addressed separately. A researcher's report neither transfers Sincliq's notification responsibilities to the researcher nor guarantees a reply within a statutory notification period.

13. Cooperation and recognition

We value factual reports and careful conduct that reduces risk to users. This policy creates no bounty program, entitlement to payment or guaranteed recognition. For paid analysis, submit a separate proposal and agree the engagement before starting work. Public acknowledgement requires agreement on the name or pseudonym and information to be disclosed. The policy grants no legal safe harbor, immunity or protection from third-party claims or authorities' actions; good faith alone does not replace required permission. Do not condition sharing basic threat information on payment. Mandatory rights and legally protected reporting remain unaffected.

Responsible entity

Sincliq Inc., 1000 Northwest Street, Mid-Town Brandy Wine, Suite 1200, Wilmington, DE 19801, USA, hello@sincliq.com.