You have SQL injection on a production app and could dump the entire customer database to prove impact. What's the responsible proof?

The goal of a penetration test is to demonstrate risk so it can be fixed — not to actually realize that risk against the client. With SQL injection, you can prove the vulnerability conclusively without ever touching real customer data.

Why minimal demonstration is correct

Extract something that proves arbitrary read access but is harmless: the database version string, the current user, the schema, a COUNT(*) of a sensitive table, or a single record with sensitive fields redacted. That evidence is unambiguous — it shows you can read data you shouldn't — yet it leaves no PII in your hands and creates no new breach. This is data minimization applied to offensive work, and it is exactly what a mature tester does.

Why the other options are wrong

• Dump the full customer database. The instant you exfiltrate real PII you have arguably caused a reportable data breach yourself, triggering notification duties under GDPR/CCPA and creating a custody-and-deletion liability for both you and the client. A bigger dump does not prove the bug any better than a row count does.
• Drop a table. This is destructive and far outside proof-of-concept. Proving write access never requires damaging production data — you can demonstrate it more safely (e.g., a benign, reversible marker in a non-production-critical field, only if authorized).
• Encrypt the database and demand a bounty. That is ransomware and extortion. It is a crime, full stop, and the opposite of the trust relationship a test depends on.

What an interviewer is probing

They want restraint and an understanding of liability. A weak candidate equates a dramatic dump with impressive impact. A strong one knows that the most professional proof is the smallest one that settles the question, because every extra byte of customer data you touch is risk you have imported onto yourself and your client.