Acceptable Use & Responsible Disclosure
VoltPhish is a phishing simulation platform. It is powerful precisely because it is convincing — which is why the rules for using it are not optional.
The one rule that matters: only run VoltPhish against people who have agreed to be tested. Your own organisation, a client engagement with signed scope and written authorisation, or a lab you own. Everything else on this page follows from that.
1. Who may use VoltPhish
You may use VoltPhish if you fall into one of the following categories, and you must be able to evidence it if asked:
- Internal security teams running simulations against employees or contractors of their own organisation, under a mandate from management and consistent with local employment and privacy law.
- Security consultancies and testers operating under a signed engagement letter or rules of engagement that explicitly authorise social-engineering testing, naming the target population and the testing window.
- Researchers, trainers and students operating entirely within a lab environment they own, using mailboxes and domains they control, with no third party receiving a lure.
2. What you must not do
- Send simulations to anyone outside the authorised scope — including customers, suppliers, family members, or another company’s employees.
- Use VoltPhish to obtain credentials, payment details, or access you are not entitled to, whatever the stated justification.
- Impersonate a real third-party brand, bank, government body or individual in a way that could be mistaken for the genuine organisation outside your authorised test population.
- Enable full credential capture without a specific, documented authorisation for it in the engagement scope.
- Retain simulation results containing personal data longer than your stated retention period or your legal basis allows.
- Remove, disable or circumvent the platform’s audit logging, warnings or rate limits.
- Use VoltPhish to harass, single out or build a disciplinary case against an individual employee. Awareness programmes exist to reduce organisational risk, not to catch people out.
Unauthorised phishing is a criminal offence in most jurisdictions. In India it may engage the Information Technology Act, 2000 — including sections dealing with identity theft, cheating by personation using a computer resource, and unauthorised access — as well as provisions of the Bharatiya Nyaya Sanhita relating to cheating and forgery. Comparable offences exist under the Computer Fraud and Abuse Act in the United States and the Computer Misuse Act in the United Kingdom. This paragraph is a general description, not legal advice; take your own advice before testing across borders.
3. Running a programme lawfully and decently
Authorisation
Get it in writing, before the first campaign, from someone with the authority to give it. For an internal programme that usually means the CISO or an equivalent executive sponsor; for a client engagement it means a signed scope document naming social engineering as in scope. Keep the authorisation for as long as you keep the results.
Employee notice
In most jurisdictions employees do not have to be told when a simulation will arrive, but they should have been told that simulations happen at all — typically through an acceptable use policy, security policy or induction. Silent, unannounced programmes with no policy basis create legal exposure and destroy trust, which is the opposite of what an awareness programme is for.
Data protection
Simulation results are personal data. If you are processing the data of individuals in India, the Digital Personal Data Protection Act 2023 applies to you as a Data Fiduciary; in the EU or UK the GDPR applies. In practice that means: identify your lawful basis, tell people in the relevant notice, collect only what you need, set a retention period, and be able to answer a data subject request about it. VoltPhish helps by not collecting submitted field values by default — keep it that way unless you have a documented reason not to.
Proportionality
Do not build lures around genuinely distressing subject matter — redundancies, bereavement, medical results, immigration status, disciplinary action. They generate high click rates and lasting resentment, and they teach nothing that a well-built payroll or courier lure would not.
4. How the platform is built to keep you honest
- No field capture by default. VoltPhish records that a submission occurred, not what was typed. Full capture is an explicit opt-in flag that logs a warning whenever it is active.
- Encryption at rest. Credentials and secrets held by the platform are encrypted with AES-256-GCM; passwords are hashed with Argon2id.
- Append-only audit log. Every campaign action is recorded, so a programme can be reconstructed and defended after the fact.
- Unguessable tracking tokens. Per-recipient tokens cannot be enumerated to reveal your audience list.
- Dry-run mode.
VOLTPHISH_MAIL_BACKEND=consolerehearses an entire campaign to.emlfiles without sending anything. - No offensive capability. VoltPhish deliberately contains no payload delivery, malware staging or post-exploitation tooling. It is an awareness platform, not a C2.
5. Licence and trademark
VoltPhish source code is licensed under the GNU AGPL-3.0-or-later. If you modify VoltPhish and make it available to others over a network, the AGPL requires you to publish your modified source. Commercial dual-licensing is available for organisations that cannot meet that obligation — contact business@xdepthsense.com.
The name “VoltPhish”, the wordmark and the logo are trademarks and are not licensed under the AGPL. Forks must be rebranded. A fork may state that it is based on VoltPhish, but may not present itself as VoltPhish or imply endorsement by XDepthSense.
Releases prior to v2.0.0 remain available under the MIT licence; v2.0.0 and later are AGPL-3.0.
6. Reporting a vulnerability in VoltPhish
If you believe you have found a security vulnerability in VoltPhish itself, please report it privately to business@xdepthsense.com. Include the affected version or commit, a description of the issue, and the steps needed to reproduce it. A proof-of-concept helps but is not required.
- Acknowledgement: within 3 business days.
- Initial assessment: within 10 business days, including our view of severity and whether we accept the report.
- Fix target: 90 days from acknowledgement for confirmed issues, sooner where the risk warrants it.
- Credit: we will credit you in the release notes and advisory unless you ask us not to.
Please test only against your own installation. Do not test against systems belonging to other VoltPhish users, do not access or modify data that is not yours, and give us a reasonable opportunity to fix an issue before publishing. Researchers who follow this policy in good faith will not be pursued by XDepthSense; we cannot waive the rights of third parties.
Vulnerabilities in the XDepthSense website or our other systems should go to the same address — see security.txt.
7. No warranty
VoltPhish is provided as-is, without warranty of any kind, as set out in the AGPL-3.0. XDepthSense is not liable for how you use it, for the consequences of a simulation you run, or for any regulatory, employment or contractual exposure arising from your programme. Responsibility for authorisation, lawfulness and proportionality rests entirely with the operator.
8. Enforcement and contact
If VoltPhish is being used against you or your organisation without authorisation, write to business@xdepthsense.com with the headers of the message concerned. We cannot disable someone else’s self-hosted installation — that is the nature of open-source software — but we will assist a legitimate investigation where we can, and we will pursue trademark misuse where the software is being passed off as an official XDepthSense service.
Questions about this policy: business@xdepthsense.com · Back to VoltPhish