Legal
Responsible Disclosure
Explains how security researchers, users, and institutions should report credible security concerns to EviWrite responsibly.
Answer
Summary
Responsible Disclosure policy for EviWrite, including reporting contact, permitted reporting boundaries, prohibited testing, no bug bounty position, and handling expectations.
Responsible Disclosure
Effective date: 1 June 2026
Last updated: 1 June 2026
This Responsible Disclosure page explains how credible security concerns relating to EviWrite should be reported.
It is intended for security researchers, users, institutions, partners, web-filtering vendors, and others who identify a possible vulnerability, misconfiguration, abuse risk, impersonation risk, or security concern affecting EviWrite’s public website, public materials, or authorised trust surfaces.
This page is not a bug bounty programme, safe-harbour guarantee, legal advice, contract, permission to access non-public systems, or authorisation to breach any applicable law.
1. Security contact
Credible security concerns should be reported to:
Reports should be clear, factual, and limited to information necessary to understand the issue.
2. Abuse contact
Abuse, impersonation, fraudulent references, false EviWrite claims, brand misuse, suspicious pages, unauthorised use of EviWrite marks, or other misuse concerns should be reported to:
Abuse reports should include the relevant links, screenshots, visible marks, public statements, claimed identities, or other information that helps EviWrite understand and assess the concern.
3. Legal and privacy contacts
General enquiries:
Legal notices and legal-policy enquiries:
Privacy and data-protection enquiries:
Only the email addresses listed on this page should be treated as public contact details for these purposes.
4. What to include in a security report
A useful security report should include, where available:
- the affected URL, route, domain, page, record, public surface, or observable behaviour;
- a clear description of the suspected issue;
- steps to reproduce the issue, if safe and lawful;
- screenshots, logs, headers, or timestamps where relevant;
- the likely impact;
- whether the issue appears to affect public pages only or a controlled authorised workflow;
- whether any third-party service appears to be involved;
- reporter contact details if a response is requested.
Reports should avoid unnecessary speculation. The strongest reports explain what happened, how it was observed, why it may matter, and what evidence supports the concern.
5. What not to include
Security reports must not include:
- unlawfully obtained material;
- private credentials;
- passwords;
- private keys;
- wallet credentials;
- confidential third-party files;
- unnecessary personal data;
- extracted non-public records;
- sensitive data taken from systems without authorisation;
- malware payloads except where strictly necessary to describe a finding safely.
If a report accidentally involves non-public data, the report should minimise exposure and should not include more data than is necessary to explain the issue.
6. Responsible reporting expectations
EviWrite expects reporters to act responsibly, proportionately, and lawfully.
Responsible reporting means:
- reporting credible concerns through the published contact route;
- avoiding unnecessary access, extraction, alteration, deletion, or disclosure of data;
- avoiding disruption to EviWrite, users, partners, or third parties;
- giving EviWrite a reasonable opportunity to review credible concerns before public disclosure;
- avoiding threats, extortion, coercion, or reputational pressure tactics;
- complying with applicable law.
A responsible disclosure route is not permission to test without limits.
7. Prohibited activity
This page does not authorise:
- unauthorised access to systems or data;
- attempts to view, extract, alter, destroy, or disclose non-public data;
- denial-of-service testing;
- service disruption;
- destructive testing;
- credential stuffing;
- password spraying;
- brute forcing;
- phishing;
- social engineering;
- physical attacks;
- extortion or threats;
- malware deployment;
- persistence mechanisms;
- high-volume automated scanning without permission;
- attempts to bypass authentication or access controls;
- attempts to access accounts, systems, records, or environments that do not belong to the reporter;
- testing against third-party systems not controlled by EviWrite.
If a researcher is unsure whether a proposed activity is permitted, they should not perform it without written permission.
8. Public website boundary
The public EviWrite website does not currently require visitors to create an account, log in, upload files, submit confidential records, connect a crypto wallet, buy tokens, hold cryptocurrency, or trade assets.
Public browsing should not be confused with authorised participation in an evidencing workflow.
Security reports should respect this distinction and should not attempt to force, simulate, or bypass private workflows unless expressly authorised in writing.
9. Authorised-channel boundary
EviWrite-backed evidential records are created through authorised channels.
Public pages, public guidance, public legal materials, and general explanatory pages do not by themselves create an EviWrite-backed record, verified status, EviWrite certification, legal approval, ownership proof, authorship determination, or authorised use of the ⓔ mark.
Security or abuse reports involving a claimed EviWrite-backed record should clearly identify the public reference, claimed mark, page, anchor, receipt, or other material being questioned.
10. Blockchain and anchoring reports
EviWrite may use public anchoring mechanisms as part of a tamper-evident evidential model.
Chains such as Polygon, Bitcoin, Ethereum, or other networks may be referenced as examples of possible anchoring infrastructure. EviWrite may use whichever anchoring mechanism, chain, provider, or verification route is most appropriate for the record type, authorised channel, operational context, and evidential purpose.
Reports involving public anchors, transaction references, verification pages, public proof surfaces, or receipt interpretation should include enough detail for EviWrite to identify the relevant public material.
Do not send private keys, seed phrases, wallet credentials, or unnecessary blockchain-account information to EviWrite.
11. No public bug bounty
EviWrite does not operate a public bug bounty unless expressly stated in writing.
Submitting a report does not create a right to payment, reward, employment, contract, attribution, public recognition, or any other benefit.
EviWrite may acknowledge useful reports at its discretion, but no reward should be assumed.
12. No broad safe harbour
EviWrite encourages responsible reporting of credible security concerns, but this page does not provide broad legal safe harbour.
Nothing on this page authorises unlawful conduct, unauthorised access, service disruption, data extraction, destructive testing, testing against third-party systems, or breach of any applicable law.
Any reporter remains responsible for their own conduct.
13. Handling of reports
EviWrite aims to review credible reports as soon as reasonably practicable.
The time needed to assess a report may depend on:
- the clarity of the report;
- the severity of the concern;
- whether reproduction is possible;
- whether third-party systems or providers are involved;
- whether legal, privacy, abuse, or evidential issues are implicated;
- whether the report concerns a public page or an authorised evidencing workflow.
EviWrite may request clarification where necessary. EviWrite is not required to respond to abusive, vague, threatening, automated, duplicative, irrelevant, or bad-faith submissions.
14. Disclosure and publication
Reporters should not publicly disclose unresolved security concerns without giving EviWrite a reasonable opportunity to assess and address them.
Public disclosure should not include:
- exploit instructions that create avoidable risk;
- non-public data;
- personal data;
- confidential records;
- credentials;
- private keys;
- operational secrets;
- information that enables abuse.
Disclosure should be proportionate, lawful, and focused on improving security rather than creating harm.
15. Third-party systems
EviWrite may depend on third-party infrastructure, networks, hosting, email, DNS, security, analytics, or other supporting providers.
This page does not authorise testing against third-party systems, even where those systems appear connected to EviWrite.
Concerns involving third-party systems should be reported responsibly and should not be used as a reason to attack, disrupt, or probe systems outside EviWrite’s control.
16. False EviWrite claims and impersonation
Reports of false EviWrite claims, fake verification pages, misuse of the ⓔ mark, impersonation, forged receipts, misleading public-proof claims, or fraudulent references should be sent to:
Where possible, include:
- the URL or public location of the claim;
- screenshots;
- the claimed EviWrite mark, receipt, record, anchor, or verification reference;
- the identity or account making the claim, if visible;
- why the claim appears suspicious.
17. Privacy and data minimisation
Reports should follow data-minimisation principles.
Do not send more information than is necessary to explain the concern. Do not send unrelated files, large data dumps, private records, confidential documents, or personal data unless specifically requested and lawful to provide.
Privacy and data-protection enquiries should be sent to:
18. Related pages
Readers should also review:
- Trust, Security and Enterprise Assurance;
- Enterprise Security Review Summary;
- Acceptable Use Policy;
- Privacy Policy;
- Data Processing and Role Allocation;
- Brand Assets and Mark Use Policy.
19. Final position
EviWrite welcomes credible, responsible security reporting.
The correct route is simple: report the concern clearly, minimise unnecessary data, avoid harm, do not access what is not yours, and do not treat this page as permission to test beyond lawful and proportionate observation.