Failure Patterns, Contracts and Official Sources
Penetration testing and the IT Act: written authorisation, scope letters and third-party systems
Why pen tests in India need written authorisation under IT Act sections 43 and 66, what a scope letter and rules of engagement should contain, and how to handle cloud, SaaS and hosting providers.
A penetration test does on purpose what sections 43 and 66 of the Information Technology Act, 2000 describe: accessing a computer system, downloading data, introducing code or disrupting service. The difference between a test and an offence is permission from the owner or person in charge of the system. That is why every VAPT engagement in India should start with a written authorisation signed by someone who has the authority to give it, a scope letter naming exactly which systems may be tested, how and when, and permission from third parties (cloud, hosting, SaaS) where their systems are touched. This guide explains what to put in those documents. It belongs to why managed security engagements fail and is general information, not legal advice.
The legal background in brief
| Provision | What it covers | Relevance |
|---|---|---|
| Section 43 | Accessing, downloading, introducing contaminants, damaging, disrupting or denying access to a computer system without permission of the owner or person in charge | Liability to pay compensation to the person affected |
| Section 66 | The acts in section 43 done dishonestly or fraudulently | Criminal offence: imprisonment up to three years or a fine up to ₹5 lakh, or both |
| Section 43A | Negligence in reasonable security practices for sensitive personal data | One reason to test at all |
| Section 72A | Disclosure of personal information in breach of a lawful contract | Testers who see personal data must keep it confidential; after the Jan Vishwas Act, 2023 this carries a penalty of up to ₹25 lakh |
| Section 70B | CERT-In; directions and audit framework | CERT-In empanelled auditors and the 2025 audit guidelines |
The words "without permission" are the key: authorisation from the right person is what makes a test lawful. A test on a system you do not own, without the owner's permission, is not made lawful by your own consent.
Who can authorise
- The owner of the system or the person in charge of it, normally a director or officer with authority over IT.
- For cloud and SaaS, your authority usually covers only your own tenant and configuration. The provider's infrastructure belongs to the provider; many publish penetration testing policies listing what customers may test without asking and what is forbidden (for example denial-of-service tests).
- For hosting and colocation, the data centre may require notice.
- For shared office networks or systems run by a parent or group company, get their written consent.
What the authorisation letter should contain
- Names of the client entity, the testing firm and the individual testers.
- A statement that the signatory has authority over the systems.
- The scope: IP ranges, domains, applications, environments (production or staging), accounts provided.
- Out of scope items, expressly listed.
- Methods allowed and forbidden (social engineering, physical testing, denial of service, data exfiltration limits).
- Time windows, with blackout periods such as month-end close or festival sales.
- Emergency contacts on both sides and a stop procedure.
- Handling of data seen during testing: no copying beyond proof, encryption, deletion after the engagement.
- Reporting: format, recipients, confidentiality.
- Validity dates.
Rules of engagement: practical points
| Topic | Good practice |
|---|---|
| Production testing | Off-peak windows, rate-limited scans, backups confirmed beforehand |
| Credentials | Test accounts created for the engagement, disabled afterwards |
| Personal data | Prove access with minimal records; do not download datasets |
| Findings of critical risk | Report immediately, not only in the final report |
| Your MSSP or SOC | Inform them, or decide deliberately to test detection, with a named person who knows |
| Evidence | Testers keep logs of their own actions to separate test activity from a real attack |
Telling your managed security provider in advance avoids a test being treated as a live incident, unless detection is part of what you are testing. Even then, a named person on your side should know.
Illustrative cost of getting it wrong
A test of a hosted web app, run without notifying the hosting provider, trips its abuse controls; the provider suspends the server for six hours during business. For an e-commerce MSME with illustrative sales of ₹2 lakh an hour, that is ₹12 lakh of lost sales, against an engagement fee of ₹1.5 lakh. A one-page notice would have avoided it.
When the test is required by a regulator or customer
If a regulator, government department or customer requires testing by a CERT-In empanelled auditor, the auditor will follow CERT-In's Comprehensive Cyber Security Audit Policy Guidelines (Version 1.0, July 2025) on scoping, evidence and data handling. Ask the auditor for its standard authorisation and scope templates. See VAPT cost and empanelled auditors.
FAQ
Can our employee test our systems without a letter?
Internal staff testing systems they are responsible for are in a different position from outsiders, but a written instruction from management is still good practice, especially for intrusive tests.
Is bug bounty legal in India?
Programmes that invite outside researchers rely on published rules that act as permission for the listed scope. Write those rules carefully, including what is out of scope and how data must be handled.
What if the tester finds evidence of a real attack?
Stop, preserve evidence and treat it as an incident. A specified incident must be reported to CERT-In within six hours of noticing it. See the CERT-In Directions guide.
Sources
- MeitY — Information Technology Act, 2000
- CERT-In — empanelled auditors and audit guidelines
- e-Gazette of India — Jan Vishwas (Amendment of Provisions) Act, 2023
