Penetration Testing Explained: How It’s Done, What to Look For, What to Expect

Penetration Testing Hub › the full series of practical guides

Most pages about penetration testing exist to sell you a penetration test. This one doesn’t. It exists so that, by the end, you understand what a pentest actually involves, what you could reasonably check yourself before spending a cent, what a professional engagement looks like from the inside, and — just as important — when you don’t need one yet.

If you read this and decide you’re fine for now, that’s a good outcome. If you read it and decide you want help, you’ll at least know exactly what you’re asking for.

What a penetration test actually is

A penetration test is a person — not a tool — trying to break into something you own, with your permission, so you can fix it before someone without permission tries. The tester uses the same techniques a real attacker would, but stops short of causing damage, writes down everything they did, and tells you how to close the gaps.

That last part is the whole point. A pentest that ends with a list of scary findings and no clear fixes has failed. A good one leaves you with a prioritised to-do list your engineers can act on and a summary your board can read.

The word gets stretched a lot in marketing. A quick automated scan is not a pentest. A compliance tick-box exercise where nobody exploits anything is not really a pentest either. If a human never tried to chain two weaknesses together to reach something that matters, you’ve had a scan with a nicer report.

Pentest vs vulnerability scan (the distinction the market blurs)

A vulnerability scan is automated. Tools like Nessus, OpenVAS or Qualys walk through your systems, compare what they find to a database of known weaknesses, and produce a list. It’s fast, cheap, repeatable and noisy. It will tell you a server is running an old version of something; it won’t tell you whether anyone could actually do anything with that.

A penetration test is manual and adversarial. The tester takes what a scan (and their own reconnaissance) turns up and asks: can I use this? Can I combine it with that? Where does it get me? The output is business impact — ‘from the guest Wi-Fi I reached the finance file share’ — rather than a count of CVEs.

Many organisations should run scans for months before they buy a pentest. If you’ve never scanned and patched, a pentest will mostly tell you what the scan would have told you, at ten times the cost. We’ve written a separate page on which one you actually need.

The types of penetration test

Each of these has its own guide on this site, following the same pattern: how it’s done, what to look for yourself, what to expect if you hire out, and where safe DIY stops.

• External network — what an attacker on the internet can see and reach: your public IPs, VPN endpoints, mail, DNS, exposed services.
• Internal network and Active Directory — what someone who’s already inside (a compromised laptop, a rogue contractor, a phished user) can do next. This is where most real breaches escalate.
• Wi-Fi — the one part of your network reachable from the car park. Encryption, rogue access points, guest-to-internal bleed.
• Web application — your customer portal, your booking system, your internal apps. Injection, broken authentication, access-control flaws.
• API — the interfaces behind those apps, which are often less protected than the front end.
• Cloud (Azure / Microsoft 365) — identity, conditional access, storage permissions, over-privileged service accounts. For most Irish organisations this is now the biggest attack surface.
• Mobile app — insecure storage, weak API calls, reverse engineering.
• Social engineering / phishing — the human layer, tested with consent and care.
• OT / ICS — plant floors, building management, SCADA. Tested completely differently from IT, because a normal scanner can stop a production line.

How a penetration test is done

Whatever the target, a professional test follows a recognisable sequence. Knowing it lets you see through vendors who skip steps.

1. Scoping and rules of engagement

Before anything technical happens, you and the tester agree what’s in scope, what’s out, what must never be touched, when testing may happen, and who to call if something breaks. This is written down and signed. It’s also where you decide black box (tester knows nothing), white box (tester gets credentials, documentation, source) or grey box (somewhere between). Narrow scope tests deeper; wide scope tests shallower for the same budget. Scope is your decision, not the vendor’s.

2. Reconnaissance

The tester finds out what exists. Externally that means DNS, certificate transparency logs, exposed services, leaked credentials, employee names from LinkedIn. Internally it means mapping the network, identifying hosts, spotting what’s talking to what. Most of this is passive — it’s the same homework a real attacker does first.

3. Scanning and enumeration

Now the automated tools come out: port scans, service version detection, vulnerability scanners, web crawlers. This is the part a scan-only vendor stops at. A pentester treats it as a shopping list.

4. Exploitation

The tester tries to actually use what they’ve found — log in with a default credential, exploit an unpatched service, abuse a misconfiguration. Carefully. A good tester will confirm a vulnerability is real with the least destructive proof possible and will avoid anything that risks an outage unless you’ve explicitly agreed to it.

5. Post-exploitation and lateral movement

One foothold rarely matters on its own. The tester asks: from here, where can I go? Can I escalate privileges? Can I reach the domain controller, the finance share, the backups? This is where the business impact is demonstrated and where the report gets its most useful findings.

6. Reporting

An executive summary in plain language, technical findings rated by severity, reproduction steps your team can follow, and prioritised remediation. We publish a sample report so you can see exactly what this looks like before you ever buy one.

7. Remediation and re-test

You fix things; the tester confirms the fixes worked. Buyers forget this stage exists. Ask about it before you sign anything.

What you can check yourself first

You can get a surprisingly long way on your own estate before anyone is hired. Each test-type guide has a full checklist; the short version that applies to almost everyone:

• ☐ Do you know what’s on your network? If you can’t list your internet-facing services, start there.
• ☐ Is MFA enforced everywhere it can be — email, VPN, admin accounts, cloud consoles?
• ☐ Have you run a vulnerability scan in the last quarter, and fixed the criticals?
• ☐ Are there any default passwords left on anything — printers, APs, switches, cameras, PLCs?
• ☐ Is your guest Wi-Fi genuinely isolated from the internal network?
• ☐ Are backups offline or immutable, and have you actually restored from them?
• ☐ Does anyone still have domain admin who doesn’t need it?
• ☐ Are old services, test boxes or forgotten subdomains still live?

If several of those are unknowns, a pentest will mostly confirm them expensively. Fix the basics first — then a test earns its cost by finding what you couldn’t.

What to expect if you hire someone

You’ll be asked scoping questions (what, when, how much access). You’ll need to nominate a contact, provide credentials for any white-box elements, and possibly agree a maintenance window. A typical engagement runs one to three weeks from kick-off to report depending on scope, with the active testing often a few days of that. Well-scoped testing carries low production risk, but not zero — which is why the rules of engagement matter.

You should expect a readable report, a debrief call, and a re-test. You should not expect a report you can’t understand, a finding without a fix, or a sales pitch disguised as an executive summary. Our what to expect guide goes through the whole thing stage by stage.

When you don’t need a pentest yet

No honest provider should sell you a test you’re not ready for. You probably don’t need one yet if you’ve never run a vulnerability scan, if MFA isn’t turned on, if you have no inventory of your systems, or if your budget only stretches to one thing this year and that thing hasn’t been ‘patch and MFA’. Do those first. Then come back.

You probably do need one if you handle sensitive personal or financial data, if you’ve just shipped something new and exposed, if a compliance framework (NIS2, PCI DSS, DORA) or a cyber insurer requires it, or if you’ve done the basics and want to know what a real attacker would find next.

Compliance triggers in Ireland

Several frameworks now expect regular testing. NIS2 requires in-scope entities to demonstrate their risk-management measures work; testing is the direct evidence. PCI DSS v4.0 requirement 11.4 mandates penetration testing for anyone handling card data. DORA brings threat-led penetration testing (TLPT) to financial entities — we have a full DORA hub on that. GDPR Article 32 expects ‘regular testing’ of security measures without prescribing how. None of these tell you what a good test looks like; that’s what the rest of this hub is for.

Choosing a provider in Ireland

Look past the trust strip. CREST membership and OSCP-certified testers are worth having, but they tell you a firm meets a baseline, not that it’s good. Better questions: can I see a sample report? Who exactly will be doing the testing, and what have they written publicly? What’s your approach to production risk? Is a re-test included? Will you tell me if I don’t need this yet? We keep an honest guide to Irish providers — including firms that aren’t us.

Common questions

Is penetration testing legal in Ireland?

Yes, when authorised. Testing systems you own or have explicit written permission to test is legal and routine. Testing anything else is a criminal offence under the Criminal Justice (Offences Relating to Information Systems) Act 2017. Every professional engagement starts with a signed scope and authorisation before a single packet is sent.

How long does a penetration test take?

Typically one to three weeks from kick-off to final report, depending on scope. Active testing is often only a few days of that; scoping, reporting and the re-test make up the rest.

What’s the difference between a pentest and a red team exercise?

A pentest finds as many vulnerabilities as it can within a defined scope and timeframe. A red team exercise tests whether your people and detection actually notice and respond to a realistic, stealthy attack against a specific objective. Most organisations need pentesting long before they need red teaming.

Will a penetration test break something?

It shouldn’t, if it’s scoped well and the tester is careful. But any active testing carries some risk, which is why you agree rules of engagement, a testing window and an emergency contact up front. Be wary of anyone who says the risk is zero.

Explore every guide in the hub

This page is educational and not legal advice. Only test systems you own or are explicitly authorised to test.