TRUST · RESPONSIBLE DISCLOSURE
Report security
vulnerabilities through a
governed channel.
vulnerabilities through a
governed channel.
Use the approved ZoikoTax vulnerability-reporting process to share potential
security findings while minimizing sensitive data and avoiding unsupported
assumptions about scope, bounty, testing authorization or response timing.
security findings while minimizing sensitive data and avoiding unsupported
assumptions about scope, bounty, testing authorization or response timing.
Report a security vulnerability
View reporting policy
Security
The report action leads to the guidance below. It is not a submission endpoint.
01 · FIND THE RIGHT PATH
A security finding needs a security route.
Use the source-defined vulnerability process once its current channel is approved. The categories below help
distinguish reporting intents; they do not define asset scope or grant permission to test.
distinguish reporting intents; they do not define asset scope or grant permission to test.
Product or platform vulnerability
Describe the suspected security behavior and observed impact. Confirm the affected surface against the exact approved asset scope before further action.
API or authentication issue
Include only minimal, safe reproduction details. Do not send live credentials, access tokens or another person’s session data.
Potential data exposure
Stop at the minimum necessary proof. Do not extract, retain or share unnecessary customer, taxpayer or payment data.
Customer configuration or support
A customer misconfiguration is not automatically a platform vulnerability. Use an approved support route when appropriate; its destination is not supplied here.
Phishing, social or physical concerns
Route these concerns only when the approved policy includes them. Their mention here does not authorize social engineering or physical testing.
Fraud, abuse or other concerns
Use a separate route only if it is registered and approved. Procurement, privacy and general support requests are not vulnerability reports.
.svg)
Where and how can I report?
First consult the current approved reporting policy, confirm scope and prepare minimal redacted evidence. Then use its verified reporting channel. That channel is unresolved in this design, so no report can be sent here.
02 · SCOPE & ASSETS
Scope must be exact. Authorization must be explicit.
No approved asset scope supplied. Do not infer ownership, currentness or testing permission from a product name, a
public route or a reachable environment.
public route or a reachable environment.
Current owned assets & conditions
Source required · Exact assets, ownership and allowed conditions are not published.
Excluded assets & activities
Source required · Exclusions must be stated by the approved policy, not inferred.
Sandbox or test environments
Not published · A sandbox is included only when expressly approved.
Retired or superseded assets
Source required · Historical references do not establish current scope.
Third-party systems
Third-party ownership is separate. ZoikoTax reporting guidance does not authorize testing another organization’s systems.
Customer environments
Customer systems and data require their own authorization. A reporting channel does not grant access to them.
An unknown asset
Seek scope clarification through an approved route when one is supplied. An unanswered scope question is not authorization to test.
03 · SAFE REPORTING BOUNDARIES
Reporting is not authorization to test.
Any permitted testing must be defined in the exact approved policy. Good intent alone does not establish
permission, legal protection or access to customer data.
permission, legal protection or access to customer data.
MINIMUM NECESSARY
Stop at minimal proof
Avoid disruption and stop when the concern can be described safely. Do not pursue unrelated access or collect customer data to make a report more convincing.
NO IMPLIED PERMISSION
Do not infer allowed methods
DoS, social or physical testing, scanning, persistence and lateral movement require exact policy treatment. None is authorized by this design.
PROTECT THE EVIDENCE
Keep sensitive details private
Use only an approved protected reporting process for exploit evidence. Do not post payloads, secrets or sensitive reproduction details publicly.
No test instructions or rates are established here
Non-disruptive testing is permitted only when approved. This page supplies no scanning permission, test rate, safe-harbor promise or conformance claim.
04 · HOW TO REPORT
A useful report is specific, minimal and redacted.
Illustrative reporting form anatomy — not an active approved channel. These data categories describe what a safe
report should cover; exact requirements and the receiving process need source approval.
report should cover; exact requirements and the receiving process need source approval.
PREPARE, DO NOT SUBMIT
Keep the finding. Leave
out the secrets.
out the secrets.
Never include a password, token, private
key or full dataset. Use a safe category
instead of unverified targets or real
customer identifiers.
key or full dataset. Use a safe category
instead of unverified targets or real
customer identifiers.
No report can be sent
from this static design
from this static design
No approved destination,
account requirement,
attachment handling or
encryption method is supplied.
account requirement,
attachment handling or
encryption method is supplied.
Contact is policy-dependent
Reporter contact is requested only if
required by the approved policy.
Anonymous reporting is not assumed.
Without a response contact, no update
delivery is promised.
required by the approved policy.
Anonymous reporting is not assumed.
Without a response contact, no update
delivery is promised.
Privacy-conscious reporting
Share only what is needed to understand
the issue. Do not include unrelated
personal information or confidential
screenshots.
the issue. Do not include unrelated
personal information or confidential
screenshots.
FORM SPECIMEN · SOURCE REQUIRED
Security vulnerability report
No live fields or submission. Required and optional designations must come from the approved policy.
Reporter contact
Only when policy-required; do not assume an account is needed.
Not entered · illustrative only
Affected surface
Use a safe category; confirm exact assets against approved scope.
Not entered · illustrative only
Issue summary
Briefly describe the suspected security behavior. Exclude secrets and identifiers.
Not entered · illustrative only
Observed impact
Describe what was actually observed, not an assumed severity or speculative outcome.
Not entered · illustrative only
Minimal safe reproduction steps
Only necessary, redacted steps within approved policy. No live payloads or expanded testing.
Not entered · illustrative only
Environment or version
Include only details needed to understand the finding.
Not entered · illustrative only
Prior disclosure
Include only if approved; omit private identities and unrelated reports.
Not entered · illustrative only
More sensitive data is not stronger evidence.
Redact secrets and customer, taxpayer and payment identifiers. Trim logs to necessary evidence. Do
not bulk-extract data. Share exploit evidence only through an approved protected process, never a
public post.
not bulk-extract data. Share exploit evidence only through an approved protected process, never a
public post.
Redacted evidence
A minimal description is preferable to unnecessary data. Do not include confidential screenshots.
Not entered · illustrative only
Attachments · unavailable
Only if permitted by the approved receiving process. File safety, formats, size limits and protected transfer
requirements are not supplied; no scanner or encryption implementation is claimed.
requirements are not supplied; no scanner or encryption implementation is claimed.
Submit unavailable · source required
Channel unresolved. Nothing has been sent, stored or acknowledged. An approved current channel is required before launch.
05 · TRIAGE & REMEDIATION
Receipt is not validation. Review is not a deadline.
Conceptual, externally governed status taxonomy — not live report status. These text meanings are illustrative and
require approved policy before use in reporter communications.
require approved policy before use in reporter communications.
RECEIVED
Receipt only; the finding has not been validated.
UNDER REVIEW
The report is being assessed under the approved process. No outcome or severity is implied.
NEEDS INFO
Only minimal, safe additional details should be requested through the approved channel.
VALIDATED
Use externally only when approved. Validation does not establish a guaranteed severity.
REMEDIATION
Work is governed by the actual policy and engineering process; no date is implied.
RESOLVED / CLOSED
The reason for resolution or closure must follow approved communication policy.
DISCLOSED / ADVISORY
Public communication occurs only through an approved disclosure or advisory process.
No acknowledgement, update or remediation timeline is established
Timing and externally visible status language must come from the current approved policy. This specimen does not guarantee a response or an outcome.
06 · REVIEW PRINCIPLES
Assess the finding, not the reporter’s reputation.
Severity, duplicate handling and abuse safeguards are source-governed. No severity scheme, scoring method or
public program terms are supplied.
public program terms are supplied.
Severity & duplicates
Use only an approved assessment method. Do not assume CVSS, a priority level or a reward. Duplicate acknowledgement, if offered, follows approved communication terms.
Noise & non-security issues
Keep communication respectful and informative. Route non-security issues to an approved support destination when registered; no support URL is established here.
Abuse & reporter privacy
Any abuse protection must remain accessible; no rate limits are specified. Threats are handled internally without public operational details. Do not expose other reporters’ data or build leaderboards.
07 · COORDINATED DISCLOSURE
Disclosure needs an approved communication process.
Confidentiality expectations and public disclosure conditions must come from approved sources. Do not assume a
default deadline, an embargo or indefinite silence.
default deadline, an embargo or indefinite silence.
Reporter communication
Use the approved channel and confidentiality terms when established. Do not force public vulnerability details or imply a guaranteed update cadence.
Vendor & customer coordination
Vendor coordination is conditional on the approved process. Customer notification is separate from reporter communication and must follow its own approved requirements.
Advisories & acknowledgement
Use only an approved advisory source. Researcher acknowledgement requires approved terms and consent. No CVE/CNA terms, incident archive or researcher credits are supplied here.
Before publishing vulnerability details
Consult the exact approved disclosure policy. No public-disclosure permission, deadline or credit terms can be established from this design.
08 · LEGAL & PROGRAM BOUNDARIES
Legal protection and rewards cannot be inferred.
Approved safe-harbor and bounty terms are not established by supplied sources. This is a source limitation, not a
statement that ZoikoTax does or does not operate a program.
statement that ZoikoTax does or does not operate a program.
EXACT LEGAL SOURCE REQUIRED
Safe harbor & authorization
Only approved Legal terms can establish permission, protection or liability boundaries. Reporting alone supplies none. No law-enforcement guarantee is made.
FORMAL PROGRAM SOURCE REQUIRED
Bounty & recognition
A monetary or recognition program requires approved published terms. No eligibility, payment, reward tier, payout or hall-of-fame terms are established here.
09 · POLICY AUTHORITY
Use the current registered source, not a specimen.
Reporting policy, scope and channel details must be owned, approved and source-controlled. This design does not
publish a policy version or substitute for the authoritative policy.
publish a policy version or substitute for the authoritative policy.
Policy source & version
Not published · Source required
Effective date & review date
Not published · Source required
Policy owner & approval
Source required · No approved public owner or contact supplied
Channel ownership & currentness
Source required · No verified reporting destination supplied
Asset scope & exclusions
Source required · No approved inventory supplied
Protected transfer & encryption
Not published · No approved key or method supplied
Approved historical archive
Not published · Superseded specimens must be labeled historical
Public launch is blocked until the policy and channel are approved
A missing, dead or stale channel, scope reference or encryption key must not be presented as usable. Publish only the current registered source; CMS content cannot originate security or legal facts.
Security evidence
Security evidence belongs in Security and the Trust Center. It is separate from vulnerability reporting.
10 · STATES & RECOVERY
An unavailable channel must look unavailable.
Conceptual UI and communication states — not runtime behavior. An approved receiving process must define error
handling, privacy, attachment constraints and any receipt message.
handling, privacy, attachment constraints and any receipt message.
DEFAULT · CHANNEL UNRESOLVED
Reporting is unavailable.
The approved current reporting channel is missing. No report has been sent.
ILLUSTRATIVE ERROR
Submission could not be confirmed.
Do not assume receipt. Consult the approved recovery guidance; no alternate destination is supplied.
ILLUSTRATIVE RECEIPT · NOT A LIVE REPORT
Receipt would not mean validation.
A future approved receipt confirms receipt only, not validity, severity or remediation.
No report ID or delivery is established here.
No report ID or delivery is established here.
Channel available
Show a usable destination only after it is approved and current. A compromised channel requires an approved alternate; none is supplied.
Submission failure
Identify the issue clearly and guide focus to it. Any safe field-preservation behavior needs approval; no autosave or storage is claimed.
Attachment rejected
Explain rejection using only source-defined constraints. Do not invent allowed formats, size limits or a receiving-file scanner.
Anonymous or no response contact
Anonymous reports are possible only if policy permits them. Without a response contact, do not promise updates.
Policy unavailable
Do not replace missing policy with industry-normal terms. The approved policy source and actual route are required before launch.
No JavaScript or assistive technology
Core policy and actual approved navigation must remain useful. Persistent labels, visible focus, clear errors and readable text meanings are design requirements, not implemented guarantees.
11 · COMMON QUESTIONS
Direct answers. No inferred terms.
The approved current policy is the authority. Where its facts are missing, the answer is source required — not an
industry assumption.
industry assumption.
How do I report a vulnerability?
Use the current approved reporting policy and its verified channel. Prepare minimal, redacted details first.
Approved channel details are not supplied in this design; no report can be sent here.
Approved channel details are not supplied in this design; no report can be sent here.
Is there a bug bounty program?
Approved bounty terms are not established by the supplied sources. Do not infer eligibility, payment or
recognition from a public reporting channel. Consult formal approved program terms if published.
recognition from a public reporting channel. Consult formal approved program terms if published.
Which systems are in scope?
No approved asset scope is supplied. Only the exact current published inventory and conditions can establish
scope. A reachable asset, customer environment or sandbox is not automatically included or authorized for
testing.
scope. A reachable asset, customer environment or sandbox is not automatically included or authorized for
testing.
What should I include in a report?
An issue summary, safe affected-surface category, observed impact, minimal safe reproduction and redacted
evidence. Include environment or version details only as needed, contact only as policy-required and prior
disclosure only if approved. Never send secrets or full datasets.
evidence. Include environment or version details only as needed, contact only as policy-required and prior
disclosure only if approved. Never send secrets or full datasets.
Can I publicly disclose a finding?
Public disclosure must follow approved communication and confidentiality terms. No deadline, embargo or
permission is established here. Do not publicly post sensitive data or exploit evidence.
permission is established here. Do not publicly post sensitive data or exploit evidence.
Does ZoikoTax provide safe harbor?
Approved safe-harbor terms are not established by supplied sources. Only exact approved Legal terms can
establish authorization or protection. Reporting is not permission to test, and no law-enforcement promise is
made.
establish authorization or protection. Reporting is not permission to test, and no law-enforcement promise is
made.
12 · CONTINUE WITH THE RIGHT INTENT
Reporting guidance first. Trust evidence separately.
Vulnerability reporting, security evidence, privacy and support are distinct intents. Do not send a vulnerability
report through a sales or procurement path.
report through a sales or procurement path.
Reporting policy & channel guidance
Return to the reporting anatomy and source requirements. The actual approved reporting route remains unresolved.
/trust/responsible-disclosure/
Review reporting guidance
Security
Explore security evidence and context. This is not a vulnerability submission endpoint.
/trust/security/
View Security
Trust Center
Find the broader Trust hierarchy. Privacy and procurement requests remain separate from reporting.
/trust/
View Trust Center