How do you define the scope of written authorization for a penetration test, and what should be in the document?

Definitely include a source IP disclosure clause. The document must specify the static external IP addresses the testing team will scan from. That way, you can distinguish the test from an actual cyberattack in your WAF and easily filter out test activities if you need to run a forensic analysis on your logs.

The contractual penalties and confidentiality clauses in the agreement should be framed around the cybercrime articles of the Turkish Penal Code and the KVKK. A legally binding protocol for immediate notification and secure deletion must be defined in the event that customer data or sensitive financial records are accessed during testing.

Don't open your live database directly to testing. Spin up a test environment that's an exact replica of production, anonymize the sensitive customer data, and run the test there. What matters to banks are the vulnerabilities in your architecture and code; there's no reason to put your live customer table at risk.

Even if you write a scope document a lot of firms out there just fire up standard automated vulnerability scanners and walk away. If you don't put a cap in the contract like 'automated scanner request rates cannot exceed X requests per second', your API gateway will lock up and your customers will get errors.

Last year we authorized a test for the 02:00-05:00 window. The tester accidentally hammered the prod queue instead of staging, and our messaging server went down for 40 minutes. Luckily we had an emergency stop clause, we killed the test in 3 minutes. Without that clause we never would have made it before the morning shift started.

edit: fixed a few typos.

Will the test be black box or white box? If you're handing source code or API documentation to the team, the clauses covering IP protection and secure destruction of code after the test become far more critical.

Don't let them ping a single port without written permission; unauthorized access can put both parties straight in front of a public prosecutor.

You're right, I've been down that road too. The real issue isn't the number, but what it's based on.

Correct me if I'm wrong.

I'll try it. When making a decision, first look at what data you have on hand.

Any unwritten clause becomes a point of disagreement later, as both sides remember it differently.

you're right. i mean if 2FA is on, a stolen password alone is useless.

having backups accessible on the same network and with the same identity makes them part of the target. btw if you post the result here, it will help others too.

Three different views emerged, they all complement each other. The real issue isnt the number but what its based on.

If you post the result here, it will help others too.

Good call starting this thread.

I agree.

Let me summarize what's been said so far. The answer varies greatly by industry; there is no one-size-fits-all rule.

If it's your first time, start small; scaling comes later. I'm also curious if anyone does it differently.

Noted, thanks. If you get three different answers on a topic, the question was asked wrong.

The real issue isn't the number, but what it's based on.

Thanks for writing this, that's the right way. Taking measures without an inventory leaves doors you haven't seen open.

This is my opinion, I'm not claiming it's absolute truth.

i didn't know that. the real issue isn't the nmuber but what it's based on.

I'd say don't rush. Everyone rushing into penetration testing written authorization gets stuck at the same point.

If you have questions write them; Ill answer as best I can.