Manual penetration testing is security testing where a person, not just a tool, tries to break into your systems the way an attacker would. Scanners find known flaws in predictable places. A human tester finds the flaws that only show up when someone works out how your business actually runs. Most good tests combine both.
For service information, visit our penetration testing and incident response page.
Key Takeaways
- Manual testing finds what scanners cannot. Business logic flaws, chained weaknesses and anything sitting behind a login.
- Almost no test is fully manual, and that is fine. Ask who performs the exploitation, not what percentage was manual.
- Ask who actually does the testing. Some providers test in-house, some subcontract. Both can work. You need to know which.
- Ask for a redacted sample report before you buy. It is the fastest way to tell a real test from a scan with a cover page.
- Australian obligations matter more than overseas ones. The Essential Eight, the Privacy Act and APRA CPS 234 are the relevant frameworks here.
What Is Manual Penetration Testing?
Manual penetration testing is security testing carried out by a person rather than a tool alone. The tester studies how your systems are meant to work, then tries to make them work differently. The goal is to show what a real attacker could achieve, not just list what might be wrong.
An automated scan does something narrower. It compares your systems against a database of known issues and reports the matches. Scans are fast, cheap and repeatable. They belong in any security programme. They just cannot think.
Here is what each one is good at.
| What needs finding | Automated scan | Manual test |
|---|---|---|
| Known software flaws and missing patches | Yes | Yes |
| Weak configuration and default credentials | Yes | Yes |
| Business logic flaws | No | Yes |
| One user reaching another user’s data by altering a request | No | Yes |
| Two small flaws chained into a serious one | No | Yes |
| Anything behind a login or a custom workflow | Limited | Yes |
| Judgement about what actually matters in your environment | No | Yes |
A scanner cannot tell you that a finding does not matter in your case. It cannot tell you that a low-rated issue is serious because of what sits next to it. That judgement is what you are paying for.
Why Almost No Penetration Test Is Fully Manual
Very few penetration tests are fully manual, and that is not a problem. Testers use tools constantly for reconnaissance, mapping and coverage checks. A tester who refuses to use tools is slower and misses more, not less.
Most buyers who search for manual testing are reacting to something. A client, an insurer or an auditor has told them a scan is not enough. That is fair. But the question to ask is not how much of the test was manual.
Ask this instead. Did a person perform the exploitation and write the findings, or did you buy a scanner export with a cover page?
| Signs you bought a scan | Signs a person did the work |
|---|---|
| Findings are a list of published vulnerability identifiers with stock remediation text | Findings include steps to reproduce them in your environment |
| Nothing refers to your business, your data or your users | Some findings would be invisible to a scanner |
| Nothing was chained, and nothing was confirmed by exploitation | Severity has been adjusted up or down, with the reasoning given |
| Severity comes straight from the scoring system | The report separates what was confirmed from what was suspected |
| You were quoted per address before anyone asked what you run | Scope was agreed in writing, including what was left out |
What Does a Manual Penetration Test Cover?
A manual penetration test covers whatever scope you agree before testing starts. Scope drives both the cost and the value, so it is worth getting right.
- External network testing. Looks at everything reachable from the internet. Perimeter devices, remote access, exposed services and public-facing applications.
- Internal network testing. Assumes an attacker is already inside, through a phishing email or a stolen laptop. It tests how far that access can spread. This is usually the more revealing exercise.
- Web application testing. Covers logins, sessions, access between user roles, input handling and the logic of the application itself.
- Cloud testing. Looks at identity, permissions and sharing rather than servers. More on this below.
- Social engineering. Tests people and process, usually through simulated phishing. It is normally scoped on its own.
For example, a law firm with a client portal and a Microsoft 365 tenancy might scope web application testing and cloud testing this year, then leave internal network testing until next year. That is a sensible choice. A test that tries to cover everything on a small budget usually covers nothing properly.
How Does Cloud Penetration Testing Work for Microsoft 365 and Azure?
Cloud penetration testing targets identity and permissions rather than servers and patches. In a Microsoft 365 or Azure tenancy, that is where the attacker route usually runs.
Testing looks at areas like:
- Conditional access gaps that allow sign-in from unexpected devices or locations
- Privilege escalation through role assignments and administrative delegation
- Guest accounts and external sharing links that outlive their purpose
- Legacy authentication that skips multi-factor authentication
- App registrations and consent grants, including permissions held by third-party apps
- Storage and sites that are more open than their owners think
One practical point. Microsoft publishes the Microsoft Cloud Unified Penetration Testing Rules of Engagement. You do not need pre-approval to test your own tenancy, but the rules still apply. Testing must stay within assets you own, and denial-of-service testing is not permitted. Any provider testing your tenancy should be able to explain those rules and how their work stays inside them. If they cannot, that tells you something.
Cloud testing is not the same as a configuration review. A review shows where your settings differ from good practice. A test shows what someone could do with the gaps. Many organisations start with a Microsoft 365 security audit to get a baseline, then test the areas that matter most. Wider cloud protection is covered in our guide to cloud security services.
How Do You Choose a Manual Penetration Testing Company in Australia?
Start by asking who will actually do the testing. Most providers look alike on their websites, so the useful signals come from what they are willing to tell you.
- Who performs the test. Ask whether testing is done by the provider’s own people or by a subcontracted specialist. Neither answer is wrong. A provider who scopes well and manages a specialist can beat one who tests in-house without the right skills. What matters is being told, because it affects accountability and who you can ask later.
- Scoping before pricing. A quote given before anyone asks what you run is a product, not a service. Expect questions about your environment, your obligations and what you would count as a bad day.
- A redacted sample report. Ask for one. Any established provider has one. Read it as if it were about you. Could your team act on it? Could your board understand the summary?
- Retesting. Check whether a retest of fixed findings is included, time-limited or charged extra. A test with no retest tells you what was wrong, not whether it got fixed.
- Australian obligations. Your rules are local. Depending on your sector they may include the Essential Eight, the Privacy Act and the Australian Privacy Principles, APRA CPS 234 for regulated financial entities, and ISO/IEC 27001 if you want certification. A provider who only talks about overseas frameworks has not thought about your situation. Testing supports Essential 8 compliance by showing whether controls work in practice, not just on paper.
- Data handling. A test report explains exactly how to break into your organisation. Ask how it is stored, how it reaches you, who can see it and when it is destroyed.
Questions to Ask a Penetration Testing Provider
- Who will perform the testing, and are they employed by you or subcontracted?
- What standards or methodologies guide your testing, and what certifications do your testers hold?
- How do you test safely against production systems, and what happens if something breaks?
- What does your report contain, and can I see a redacted example?
- Is a retest of fixed findings included?
- How do you handle and destroy the findings after the engagement?
- How long will the work take from scoping to final report?
The answers matter less than the willingness to give them. A provider who is vague about who does the work, or who cannot show a sample report, has already told you what you need to know.
What Do You Receive at the End of a Penetration Test?
You should receive a report you can act on, plus a retest that confirms the fixes worked. A complete deliverable usually includes the following.
- An executive summary a non-technical reader can use. It should state the overall risk position plainly and name the two or three things that matter most.
- Technical findings with evidence, steps to reproduce and affected systems, so your team can check each one rather than take it on trust.
- Risk ratings with context. A standard score is a starting point. The rating should reflect what the finding means for you.
- Prioritised remediation guidance that separates fix now, plan for later, and accept as a documented risk.
- A remediation conversation. Reports are easier to act on when you can ask questions about them. Check whether that is included or charged.
- Retest results confirming which findings are closed and which are still open.
How Kloudify Supports Penetration Testing and Remediation
Kloudify works with Australian organisations running Microsoft environments. Penetration testing sits alongside our wider cyber security services. When testing finds problems in identity, email, endpoints or cloud settings, the fix is the same work we do every day. That shortens the gap between finding a problem and closing it.
You can see an example of security work in a Microsoft environment in our Strategix case study.
To talk through scope, timing and what testing suits your environment, get in touch with our team.
The Bottom Line
The bottom line: manual penetration testing is worth paying for when you need to know what an attacker could actually do, not just what software is out of date. Judge providers on three things. Who performs the testing. Whether they scope before they quote. Whether a retest is included. If a provider will not show you a redacted sample report, keep looking.
If you are scoping a test for a Microsoft environment, start with what you need to prove and to whom. That decides the scope, and the scope decides everything else.
Frequently Asked Questions
They include scoping the work, human-led testing of the agreed systems, and a report with evidence and prioritised fixes. Scope may cover external and internal networks, web applications, cloud environments or social engineering. Most engagements include a retest, but confirm that before you sign.
Ask who will do the testing, request a redacted sample report, and check whether a retest is included. Choose a provider who scopes your environment before quoting rather than pricing per address. One who understands the Essential Eight and the Privacy Act is more useful than one who only cites overseas frameworks.
No. A scan compares your systems against a database of known issues and reports the matches. A manual test involves a person exploiting weaknesses, chaining them together and working out what an attacker could achieve. A scan says what might be wrong. A test says what someone could do with it.
Yes. Cloud testing examines identity, conditional access, privilege escalation, guest and external sharing, legacy authentication and app permissions rather than servers and patches. Microsoft publishes the Microsoft Cloud Unified Penetration Testing Rules of Engagement, and your provider should be able to explain how their work stays inside them.
Cost depends on scope, not a standard rate. The main drivers are how many systems are in scope, how complex they are, whether testing is external, internal or both, and whether a retest is included. Be careful with a fixed price quoted before anyone asks what you run. It usually means an automated scan.
Most organisations test once a year, and again after a major change such as a new application, a migration or a restructure of access. Compliance obligations or client contracts may set the frequency for you. A single test gives you a snapshot that ages quickly.

