How I handle access and data

You are trusting me with the part of your app you are most worried about. This is what I do with that access.

Last updated 22 September 2026.

Before anything is tested

Nothing is tested until you have agreed, in writing, what I may look at, on which environment, and for how long. I stay inside that scope. If I notice something outside it, I stop and tell you rather than keep going.

Access

• Read-only access wherever it is enough, and test accounts rather than your real users' accounts.
• I don't write to your production data during an audit.
• Fixes happen on a branch or a staging copy, and only go live when you approve them.

Secrets and credentials

• Please don't email me keys or passwords. If I need access, a temporary key or an invited account you can remove me from is better.
• I don't keep credentials after an engagement ends, and I will remind you to rotate anything you shared.
• If I come across an exposed secret during an audit, I tell you straight away rather than waiting for the report.

Your data and your users' data

• I look at what I need to confirm a finding, and avoid copying your users' personal data.
• Anything I do hold for the work is deleted when the engagement ends.
• If you are in the EU or UK and need a data processing agreement, I will sign one before I get access.

Confidentiality

• I am happy to sign your NDA before you share anything.
• Reports go only to the people you name. I never publish findings about a client's app.
• If I would like to mention our work in my portfolio, it is anonymous, and only with your written approval of the exact wording.

This site

This site sets no cookies, runs no trackers, and serves everything from its own domain. My accounts for email, hosting, domain and code use two-factor authentication.

Reporting a vulnerability

If you have found a security issue in this site, email asad@auditmyapp.dev. Contact details for researchers are also published at /.well-known/security.txt, the standard location for them.