Responsible Disclosure Policy
Last updated: May 31, 2026
Document owner: Chief Information Security Officer (CISO)
Policy steward: Security Engineering
Review cadence: Quarterly and after material architecture changes
Effective date: 2026-05-31
Applies to: EthicPages production systems, services, and managed infrastructure
Primary contact: ethicpages+contact@invictosoft.com (subject: Responsible Disclosure)
Purpose and commitment
EthicPages welcomes good-faith security research that helps us protect customers, users, partners, and the public. This Responsible Disclosure Policy explains how to report potential vulnerabilities, what legal safe harbor we provide when research is conducted responsibly, how quickly we respond based on severity, and how coordinated disclosure is handled to avoid unnecessary risk.
Security and trust are core operating requirements for EthicPages. We publish this policy to make expectations transparent, reduce uncertainty for researchers, and ensure all parties can collaborate in a consistent and ethical way. This policy is aligned with our Security Overview, Privacy Policy, Data Processing Agreement, and Terms of Service.
We encourage reports that are specific, reproducible, and technically clear. We commit to acknowledging valid submissions, treating researchers respectfully, and providing progress updates throughout the investigation lifecycle.
Scope
The systems in scope are those owned, operated, or directly managed by EthicPages. We focus on vulnerabilities that materially affect confidentiality, integrity, or availability.
| In-scope asset category | Examples | Typical valid findings |
|---|---|---|
| Web application | ethicpages.com, app routes, account and billing flows | Auth bypass, IDOR, privilege escalation, CSRF, XSS, sensitive data exposure |
| APIs and backend services | Public and authenticated API endpoints | Broken access control, injection, mass assignment, auth token leakage |
| Customer workspace boundaries | Multi-tenant isolation controls and access paths | Tenant data separation failures, cross-tenant access |
| Authentication and session management | Login, logout, password reset, session lifecycle | Session fixation, token reuse, insecure reset workflows |
| Hosted Trust Center pages | Public customer trust pages managed by EthicPages | Unauthorized editing paths, admin workflow bypass, cached data leaks |
| Core integrations | Payment, email, and infrastructure integrations under our control | Misconfigured webhook validation, replay handling defects, unsafe callback handling |
Explicitly out of scope
The following are out of scope for this policy because they are low-risk, not actionable, require unrealistic assumptions, or are owned by third parties.
| Out-of-scope category | Examples |
|---|---|
| Social engineering or phishing | Attacks against employees, customers, or partners without a software vulnerability |
| Denial-of-service testing | Volumetric traffic floods, intentional service degradation, load attacks |
| Physical security | Office access controls, hardware theft scenarios |
| Third-party vendor vulnerabilities | Issues that exist solely in vendor infrastructure with no EthicPages misconfiguration |
| Clickjacking on non-sensitive pages | Pages with no authenticated action or security impact |
| Rate-limit observations without impact | Claims lacking abuse scenario, data impact, or privilege gain |
| Self-XSS requiring browser console use | Any issue requiring user to paste payload in developer tools |
| Best-practice suggestions without exploitability | Missing headers or informational findings with no practical risk |
If your report touches a mixed case (partly in scope, partly out of scope), include all evidence; we will separate and evaluate each component.
Good-faith safe harbor
We provide safe harbor for researchers who act in good faith, follow this policy, and avoid user harm. We define good faith as security testing aimed solely at identifying vulnerabilities and helping EthicPages remediate risk.
EthicPages will not initiate legal action against researchers for accidental, non-disruptive violations of our terms that occur during authorized good-faith testing under this policy, provided the researcher:
- Avoids privacy violations, destructive behavior, or service disruption.
- Stops testing and reports promptly once sensitive data exposure is observed.
- Does not access, modify, delete, or retain data beyond what is strictly necessary to prove vulnerability existence.
- Does not publicly disclose details before coordinated disclosure timelines are met.
- Does not use automated or manual testing methods that materially degrade service reliability.
- Does not attempt extortion or conditional disclosure.
This safe harbor does not apply to unlawful activity, intentional disruption, threats, privacy abuse, or attempts to monetize access to affected systems or data.
Reporting process
Please send reports to ethicpages+contact@invictosoft.com with clear technical evidence and reproducibility details.
| Required report element | What to include |
|---|---|
| Title and summary | One-paragraph risk summary in plain language |
| Affected asset(s) | URL, endpoint, environment, and account role assumptions |
| Vulnerability type | OWASP-style category if known |
| Reproduction steps | Numbered steps from clean state to exploit outcome |
| Proof of concept | Minimal payload, request/response snippets, and screenshots if useful |
| Impact analysis | Realistic attacker outcome (data exposure, privilege gain, integrity loss) |
| Suggested remediation (optional) | Concrete mitigation ideas, if available |
| Disclosure history | Whether issue was reported elsewhere or publicly referenced |
Reports that contain enough detail to reproduce quickly move faster through triage and remediation.
PGP encryption (optional)
If your report includes sensitive evidence, you may request a PGP public key via ethicpages+contact@invictosoft.com and encrypt your submission. PGP is optional; standard email is accepted for most reports. If we identify unusually sensitive material in unencrypted submissions, we may ask to move follow-up details to encrypted channels.
Triage and severity model
EthicPages uses a risk-based model informed by CVSS-style factors, exploitability, business context, and potential customer impact.
| Severity | Typical impact profile | Initial response SLA | Target remediation window |
|---|---|---|---|
| Critical | Unauthenticated remote compromise, active data exfiltration path, cross-tenant compromise | 24 hours | 72 hours for immediate mitigations; permanent fix as soon as safely deployable |
| High | Significant auth bypass, sensitive data exposure with realistic exploit path | 1 business day | 7 calendar days |
| Medium | Privilege or integrity impact requiring constraints, limited data exposure | 3 business days | 30 calendar days |
| Low | Limited practical impact, high attack complexity, or constrained abuse path | 5 business days | Next planned security release cycle |
| Informational | Observation with no exploitable risk | 10 business days | Best-effort, no fixed SLA |
SLA clocks begin when a complete, reproducible report is received. For incomplete reports, we respond with clarification requests and begin formal SLA tracking once necessary details are provided.
Response lifecycle
Our coordinated response lifecycle is designed to keep researchers informed while minimizing risk to customers.
| Stage | EthicPages commitment | Researcher expectation |
|---|---|---|
| Acknowledgment | Confirm receipt and open tracking record | Provide contact method and report ID references |
| Validation | Reproduce issue, assess scope, assign severity | Answer clarifying questions promptly |
| Containment | Apply interim controls for high-impact findings | Avoid further probing unless requested |
| Remediation | Design, review, and deploy permanent fix | Re-test if invited, confirm closure evidence |
| Communication | Share closure status and disclosure timeline | Respect coordinated disclosure dates |
For Critical and High findings, we may implement temporary mitigations immediately, including endpoint restrictions, configuration hardening, or feature gating while a full fix is validated.
Coordinated disclosure and publication
EthicPages supports coordinated disclosure. We ask researchers not to publish technical details until:
- We confirm remediation is deployed, or
- A mutually agreed disclosure date is reached.
Standard disclosure target is 90 days from report acknowledgment for complex vulnerabilities; shorter timelines are common for straightforward fixes. For critical vulnerabilities with active exploitation indicators, disclosure timing may be adjusted to prioritize user protection and incident response obligations.
If publication occurs, we request that details be accurate, avoid exposing customer data, and include remediation status. When appropriate, EthicPages may publish an advisory and credit the researcher.
Recognition and acknowledgments
We value meaningful contributions and may publicly acknowledge researchers who submit valid reports, subject to researcher preference and legal constraints.
| Recognition type | Eligibility | Notes |
|---|---|---|
| Hall of Thanks | Valid vulnerability with clear report quality | Name/handle published only with consent |
| Private appreciation | Any valid report where public listing is declined | Direct thank-you and closure notes |
| Coordinated advisory mention | High-impact findings remediated and disclosed | Technical details and timelines may be summarized |
EthicPages does not currently operate a guaranteed monetary bug bounty program under this policy. If incentives are available in the future, terms will be published separately.
Testing guidelines and ethical boundaries
To keep customers safe, we require conservative testing methods:
- Use only accounts and data you own or are authorized to test.
- Keep proof-of-concept scope minimal and non-destructive.
- Avoid persistent access, backdoors, and privileged footholds.
- Do not alter or delete customer data.
- Do not attempt lateral movement across tenant boundaries after confirming vulnerability existence.
- Stop immediately and notify us if you discover unexpected sensitive data.
Violations of these boundaries may result in safe harbor revocation and legal escalation.
Duplicate reports and prior knowledge
EthicPages evaluates reports in order of receipt with attention to technical quality and exploit specificity.
| Scenario | Handling approach |
|---|---|
| Exact duplicate | First complete valid report receives primary acknowledgment; later duplicates are tracked as corroborating signals |
| Related but distinct variant | New variant may receive separate validation and recognition |
| Known issue in remediation | Reporter is informed issue is already being addressed; additional exploit details may still improve priority |
Third-party dependencies
If an issue originates in a third-party library, platform, or provider:
- We assess whether EthicPages configuration or implementation increases risk.
- We apply compensating controls where possible.
- We coordinate with the vendor under responsible disclosure norms.
Please avoid direct publication of zero-day vendor findings through EthicPages channels unless coordination is already underway.
Legal and policy cross-links
This policy should be read with:
- Security Overview for technical safeguards and incident handling.
- Privacy Policy for personal data practices.
- Terms of Service for platform usage obligations.
- Data Processing Agreement for processor commitments.
- Accessibility Statement for inclusive service commitments.
- Vendor Code of Conduct and Modern Slavery Statement for broader ethical governance.
- ESG Commitments for governance and accountability context.
Contact and escalation
| Inquiry type | Contact channel | Expected first reply |
|---|---|---|
| New vulnerability report | ethicpages+contact@invictosoft.com (subject: Responsible Disclosure) | Within SLA by severity |
| Status request for open report | Same email with prior reference ID | 2 business days |
| Urgent active exploitation concern | Same email, prefix subject with "URGENT" | As fast as practical, target same business day |
| Policy clarification | Same email (subject: Disclosure Policy) | 5 business days |
Policy updates
We may revise this policy to reflect changes in system architecture, legal requirements, or security operations maturity. Material updates will be reflected in the "Last updated" field and linked from our legal index.
By reporting under this policy, you acknowledge that ethical testing, user safety, and coordinated remediation are non-negotiable requirements. EthicPages is committed to partnering with the security research community in a transparent, respectful, and impact-focused manner.