Guides

What Is Penetration Testing? (Ethical, Authorised Only)

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

Penetration testing (ethical, authorised only) is a time-boxed project where trusted testers attempt to find weaknesses in systems named in a written agreement, then deliver a clear report so the blue team can fix them. It is not random hacking, not a weekend surprise scan of a neighbour, and not a tool exploit walkthrough. This guide stays high-level: phases, rules of engagement, and reporting.

Permission + scope + RoE → test within fences → findings → fix-oriented report → retest
Tools are optional detail — judgement and ethics are not
Blue team is the customer of the report

What do I need before this guide?

• Comfort with basic networking and “own lab first” habits.
• Safe vulnerable lab setup for isolation ideas.
• Optional: Nmap ethical basics, OWASP Top 10 explainer.

What is penetration testing (and what it is not)?

Is:

1. Authorised security assessment with a start and end date.
2. Attempt to demonstrate impact inside agreed limits.
3. Documentation that helps owners reduce risk.
4. Often paired with vulnerability assessment, but focused on proving realistic issue chains as allowed.

Is not:

1. Anonymous scanning of the internet for fun.
2. “Pentesting” a friend’s Instagram without paperwork.
3. Bug bounty on a target that forbids your method — read program rules.
4. A substitute for secure design, patching, MFA and backups.

What do the high-level phases look like?

Vertical phase map (names vary by firm — ideas matter):

1. Pre-engagement — contracts, scope, RoE, contacts, emergency halt.
2. Intelligence / recon — learn the authorised attack surface (high-level).
3. Threat modelling / planning — prioritise what matters to the business.
4. Assessment — controlled testing within RoE (tools differ; not listed as recipes here).
5. Analysis — remove false positives; rate severity honestly.
6. Reporting — executive summary + technical findings + fixes.
7. Debrief / retest — confirm fixes; update residual risk.

What belongs in rules of engagement?

Minimum RoE checklist:

1. Exact IP ranges, domains, apps, cloud accounts — inclusions and exclusions.
2. Allowed time windows (avoid peak sales if required).
3. Forbidden actions (example categories: denial-of-service, social engineering — only if excluded).
4. Data handling: where evidence lives; retention; encryption at rest for notes.
5. Emergency contacts and stop conditions (production down → halt).
6. Disclosure path: who hears findings first (never Twitter first).
7. Legal entity names and signatures / ticket IDs.

How should a report help the blue team?

Vertical report spine:

1. Executive summary — business language, top risks, overall posture.
2. Scope reminder — what was and was not tested.
3. Methodology — high-level phases, not a weaponised script dump.
4. Findings table — ID, title, severity, affected asset, status.
5. Each finding — description, impact, evidence (safe), reproduction at minimum needed detail for the owner, remediation, references (OWASP/CWE-style).
6. Strategic recommendations — MFA gaps, patch SLAs, segmentation themes.
7. Retest plan — when and how confirmation happens.

Blue-team friendly habits:

1. Severities calibrated — not everything is Critical.
2. Fixes that map to owners (app team vs IT vs cloud).
3. Clear “validated / assumed” labels.
4. No password dumps in email bodies.

Real incident: Equifax (2017) — why findings must become fixes

The Equifax breach (2017) is a landmark reminder that knowing about vulnerabilities is worthless without patch and verification discipline. Pentest or scan reports that sit in inboxes do not reduce risk. The ethical tester’s job includes making the report usable; the organisation’s job includes fixing and retesting.

Takeaways (vertical):

1. Detection/assessment without remediation ownership fails.
2. Internet-facing apps need fast patch loops.
3. Reports should name residual risk if fixes slip.
4. Executives need plain language, not only tool output.
5. Retest closes the loop.
6. Pair assessments with backups and IR — tests are not DR.

Red Team vs Blue Team (engagement framing)

Red (in an authorised pentest)

• Stay inside RoE even if a shiny path sits one IP outside.
• Escalate human discovery of critical live issues per the contact tree.
• Prefer proving impact with least harm.

Blue

• Provide accurate asset lists and maintenance windows.
• Receive findings without blame theatre; open tickets.
• Patch, config-fix, retest; update detections where relevant.
• Ask clarifying questions — good reports welcome dialogue.

How do I practise ethically as a beginner?

Step 1 — Paper skills first

1. Write a fake RoE for your own home lab (still useful muscle).
2. Draft an empty findings table with severity definitions you choose.

Step 2 — Own-lab discovery only

1. Use isolation from the safe lab guide.
2. Practise authorised host discovery notes (Nmap ethical).
3. Stop before any exploit recipe hunting on the public web for “easy shells”.

Step 3 — Study public disclosure etiquette

1. Read a vendor’s bug bounty policy end to end.
2. Note out-of-scope items.
3. Practise writing one fictional finding aimed at a blue-team reader.

Step 4 — Career framing

1. Learn networking, Linux, web basics, cloud IAM — depth beats tool trivia.
2. Mention lab isolation and sample reports in interviews.
3. Certifications can help later; ethics stories matter on day one.

Care-take — stay ethical when curiosity spikes

1. No authorisation → no test.
2. Scope creep → ask in writing before touching.
3. Found something huge → use the emergency contact, do not “explore more”.
4. Client data in your notes → protect it like production.
5. After project → delete or archive per contract.
6. Teach juniors RoE before tool theatre.

How do I fix common pentest beginner mistakes?

Ghabru naka 😅 — these are the usual ones: