What happens to your data.
A penetration test means handing a stranger access to systems that matter, and then trusting them with whatever falls out of it. Here is exactly what I collect, where it lives, how long I keep it and what happens at the end — written to be read rather than to be defensible.
What gets collected
Evidence, not data. A finding needs enough to prove it exists and enough for your engineers to reproduce it: the request, the response, the conditions. It does not need your customer table.
Where a vulnerability exposes personal or sensitive information, I record the minimum that demonstrates the exposure — typically a single record, with identifying fields masked at the point of capture rather than redacted later. If proving an issue would require extracting data at volume, I stop and describe the extraction path instead of walking it.
Where it lives
On an encrypted disk on hardware I control, in a per-engagement directory. Not in a shared drive, not in a note-taking service that syncs somewhere, not in an AI tool.
Credentials you issue me for testing go in a password manager and nowhere else. They are never committed to a repository, pasted into a ticket, or reused across engagements.
How long I keep it
Working evidence is deleted 30 days after the retest concludes, or immediately on request — whichever comes first. The 30 days exist so that a question in week three can still be answered properly.
The final report is kept for 12 months so that a follow-up engagement can be scoped against what was found last time. If you would rather I did not, say so and I will delete my copy at sign-off. You will still have yours.
Nothing is retained as a “sample” or a portfolio piece. The sample report on this site describes a fictional company for exactly that reason.
Who else sees it
Nobody. Engagements are not subcontracted without asking you first, and no third-party service processes your findings. That includes AI tools: your report is not pasted into one for summarising, editing or drafting.
If I find something I was not looking for
Occasionally a test surfaces something outside its scope — an exposed credential, evidence of a prior compromise, personal data somewhere it should not be. I tell you promptly and privately, and I do not investigate further without you asking me to.
If a test appears to have caused an outage or data loss, you hear about it from me immediately, before I try to work out whether it was actually my fault.
Disclosure
Findings from your engagement are yours. I do not publish them, present them, or write about them — including anonymised — without written permission.
The one exception is a vulnerability in third-party software discovered during your engagement, which I would want to report to that vendor. I would ask you first, and the report would describe the flaw without identifying you.
What I will not do
Test systems you do not own or have written authorisation for. Social-engineer your staff unless it is explicitly in scope and agreed in writing. Perform denial-of-service testing against production. Retain access after an engagement closes.
Reporting a problem with this site
If you find a vulnerability in amansploit.com itself, I would like to know. See security.txt for contact details and a PGP key, or just email aman.s.732002@gmail.com. No bounty, but genuine thanks and credit if you want it.
Anything here you would want changed for your engagement, say so before we start and we will write it into the scope. It is easier to agree now than to discover a mismatch afterwards.