Black Box vs Grey Box vs White Box Penetration Testing: Which Does Your Australian Business Need?

Black box, grey box and white box penetration testing describe how much information testers get before they attack. Black box means almost none (like an external stranger). White box means full access to architecture, code or admin credentials. Grey box sits in the middle with limited credentials or documentation. For most Australian SMBs, grey box is the default that gives the best depth for money; black box suits a pure outsider simulation, and white box is for deep application or architecture reviews.

This guide explains what each approach covers, how it differs from external vs internal testing, when Australian frameworks like Essential Eight, the Privacy Act and APRA CPS 234 push you toward more knowledge, and how to choose a scope without overpaying. It pairs with our guides on external vs internal penetration testing and vulnerability assessment vs penetration testing.

What is black box vs grey box vs white box penetration testing?

The three "box" colours are about tester knowledge and access, not about whether the test is external or internal. NIST's SP 800-115 frames this as the amount of information provided to the assessment team before testing starts. In buyer language:

• ▸Black box: testers get little or no prior detail. Often only a company name, a domain or a list of public IP ranges. They discover the rest themselves.
• ▸Grey box: testers get limited but useful access, such as a standard user account, VPN access, basic architecture notes or API documentation. Enough to go deeper than a stranger, not enough to skip discovery entirely.
• ▸White box: testers get extensive information: source code, network diagrams, admin credentials, cloud role inventories or full design docs. The goal is thorough coverage, not surprise.

These labels are sometimes called covert/overt, opaque-box/clear-box, or zero-knowledge/full-knowledge testing. The idea is the same: more knowledge usually means more depth in the same number of days.

How this differs from external vs internal

External vs internal answers where the attacker starts (internet vs inside the network). Black/grey/white answers how much they know. You can combine them:

• ▸External black box: classic internet-facing test with no credentials.
• ▸Internal grey box: VPN or LAN access plus a normal user account.
• ▸Web app white box: authenticated testing with source code or detailed API specs.

If someone only says "we need a black box pentest," ask which surface and which question they need answered. The colour alone is not a scope.

What does a black box penetration test include?

A black box pentest models an attacker with no insider access: reconnaissance, discovery, and exploitation of what they can find from the outside (or from a zero-knowledge foothold). It is useful when you want to know what a stranger, a scripted attacker or a leaked-domain hunter could achieve.

Typical black box activities

1. Open-source reconnaissance: domains, subdomains, employee-facing portals, leaked credentials in public dumps (where legally allowed in scope), and forgotten staging sites.
2. Service and application discovery: what is listening, what versions are exposed, which login portals exist.
3. Unauthenticated exploitation attempts: misconfigurations, unpatched edge devices, default credentials on exposed services, and public-facing application flaws.
4. Evidence and impact: proof that a finding is real, not a scanner false positive.

Strengths

• ▸Closest to an opportunistic external attacker.
• ▸Good answer for many insurance and customer questionnaires that ask "have you been independently tested from the internet?"
• ▸Forces discovery of shadow IT and forgotten assets.

Limits

• ▸Testers spend billable time on recon that you already know.
• ▸Authenticated attack paths (most real breaches after phishing) are out of reach unless they break in first.
• ▸In a short engagement, depth on any one app is limited.

Our published case study of an internal black-box engagement on Azure-hosted Windows servers for a financial services client still found serious issues (default credentials on a monitoring platform, cleartext remote access, no account lockout) without prior credentials. Black box can be powerful when the environment is soft. It is not always the most efficient first test for a mature SaaS or hybrid estate.

What does a grey box penetration test include?

A grey box pentest gives testers limited credentials or documentation so they can spend more time on privilege escalation, business logic and lateral movement instead of guessing logins. For Australian SMBs buying a fixed-fee engagement, this is usually the sweet spot.

What "limited knowledge" usually means

• ▸A standard user account in Microsoft 365, Active Directory or the target app.
• ▸VPN or jump-host access for an internal component.
• ▸A brief asset list: critical apps, in-scope IP ranges, cloud tenancies.
• ▸Non-admin API keys or test tenants for SaaS products.

Why grey box finds more in the same week

Most modern attacks do not start with a zero-day on your firewall. They start with a phished user, a reused password or a compromised supplier account. Grey box starts closer to that reality. Testers can immediately:

• ▸Test broken access control between user roles.
• ▸Attempt privilege escalation from a normal account.
• ▸Abuse OAuth grants, shared mailboxes and over-broad groups.
• ▸Walk authenticated API and web application flows against the OWASP Top 10.

That is why many Australian providers default to grey box unless the buyer specifically wants an outsider simulation.

Strengths

• ▸Better depth per dollar than black box for the same duration.
• ▸Models the "assume breach" path that ransomware and business email compromise actually use.
• ▸Still independent: testers are not your MSP or your developers marking their own homework.

Limits

• ▸Slightly less "surprise factor" than pure black box.
• ▸Scope must still be written carefully so limited access does not quietly become full admin access.

What does a white box penetration test include?

A white box pentest (sometimes called clear-box or glass-box) gives testers deep access to design, code or privileged accounts so they can systematically cover more of the attack surface. It is the thorough option when the risk of missing something matters more than simulating ignorance.

Common white box inputs

• ▸Application source code or infrastructure-as-code repositories.
• ▸Architecture diagrams and data-flow maps.
• ▸Admin or break-glass credentials in a controlled test environment.
• ▸Cloud IAM inventories (AWS, Azure, GCP).
• ▸Threat models or previous assessment reports.

When white box is worth it

• ▸Pre-launch review of a customer-facing or AI-powered application.
• ▸High-value payment, health or identity systems.
• ▸After a major rebuild, when you want coverage not theatre.
• ▸When developers will act on line-level findings and need precise remediation.

Strengths

• ▸Highest coverage of business logic, authz flaws and design weaknesses.
• ▸Efficient for complex apps: testers do not burn days reverse-engineering what the code already shows.
• ▸Strong evidence for boards and regulators that you tested thoughtfully, not just the front door.

Limits

• ▸Needs more prep from your side (repos, environments, access).
• ▸Can feel less like a "real hacker" exercise if stakeholders expect cinematic black-box drama.
• ▸Cost and calendar time often rise with the size of the codebase or cloud estate.

White box is not automatically "better" than grey box. It is better when the question is "have we looked deeply enough?" rather than "what could a stranger do in a week?"

Which approach should Australian SMBs choose first?

Choose grey box for most first human-led pentests; choose black box when you specifically need an outsider simulation; choose white box when the application or architecture risk justifies deeper access. Match the colour to the decision you need to make.

Pick black box if:

• ▸A customer or insurer simply wants proof of independent external testing.
• ▸You suspect forgotten internet-facing assets and want discovery stress-tested.
• ▸You have never been tested and need a blunt baseline of public exposure.

Pick grey box if:

• ▸You run Microsoft 365, SaaS apps or an internal network where a phished user is the realistic start.
• ▸You want authenticated web or API testing without handing over source code.
• ▸Budget is fixed and you want maximum useful findings in 5–10 business days.

Pick white box if:

• ▸You are launching or significantly changing a web app, API or cloud workload.
• ▸You handle health, financial or large volumes of personal information and need deeper assurance.
• ▸Your developers will remediate from detailed technical findings, not only an executive summary.

Unsure? A short scoping call is cheaper than buying the wrong colour. We will usually recommend the smallest knowledge level that answers the question your buyer, insurer or board is actually asking.

How do Essential Eight, Privacy Act and CPS 234 affect the choice?

No Australian law says "you must buy a grey box pentest," but several frameworks reward testing that reflects real access paths and protects personal and critical information. Knowledge level should follow risk, not marketing labels.

Essential Eight

The Essential Eight maturity model is a control maturity framework, not a pentest standard. Black box external testing helps check internet-facing patching and exposure. Grey or white box testing helps show whether privilege restriction, MFA and application control hold once someone has a foothold. Neither replaces a control-by-control Essential Eight assessment. See our ML1 vs ML2 guide for what each level expects.

Privacy Act and Notifiable Data Breaches

Under APP 11, organisations covered by the Privacy Act must take reasonable steps to protect personal information. The OAIC's APP 11 guidance covers technical and organisational measures. If personal information lives behind logins (most of it does), unauthenticated black box alone is a weak answer to "did we test where the data actually is?" Grey or white box authenticated testing of those systems is closer to reasonable steps. That is general information, not legal advice.

The OAIC reported 1,205 NDB notifications in calendar year 2025, the highest since the scheme began, with malicious or criminal activity a major driver. Many of those paths start with credentials. Testing with some knowledge mirrors that pattern.

APRA CPS 234

CPS 234 requires APRA-regulated entities to test information security controls through a systematic program run by skilled, functionally independent specialists. CPG 234 emphasises testing controls that protect assets exposed to untrusted environments. Suppliers to banks, insurers and super funds are often asked for similar evidence. In practice that points to regular external testing plus deeper (often grey or white box) testing of systems that hold regulated data.

SOCI Act

Responsible entities under the Security of Critical Infrastructure Act 2018 need risk management programs that reflect how critical assets are actually accessed. Treat box colour as a design choice inside that program, not a compliance checkbox by itself.

How much do black, grey and white box pentests cost in Australia?

Price is driven by scope (IPs, apps, cloud accounts, code size) and depth, not by the word "black" or "grey" on the quote. More knowledge can make a short engagement more efficient; large white box code reviews can cost more because coverage expectations rise.

Aussie Pentest publishes fixed-fee starting points for human-led work:

• ▸Basic, from $5,000 + GST: external network penetration test, up to 25 IP addresses, typically delivered in 5–10 business days (often black or lightly grey).
• ▸Standard, from $12,000 + GST: external and internal network testing, up to 50 IPs and 2–3 web applications, with executive summary and debrief (commonly grey box for authenticated parts).
• ▸Advanced, from $20,000 + GST: fuller external and internal coverage, web apps and APIs, plus social engineering where scoped.

If you are not ready for a human-led engagement, an automated security assessment from $80 to $2,000 gives an analyst-reviewed baseline of external exposure. That is a triage scan, not a penetration test. Our penetration testing cost guide explains the scope drivers in more detail.

What should you prepare for each approach?

Black box needs accurate public asset authorisation. Grey box adds safe test accounts. White box adds repositories, diagrams and a stable test environment. Skipping prep wastes engagement days.

1. Authorisation: written approval for every domain, IP range and cloud tenancy in scope, including those hosted by an MSP.
2. Rules of engagement: testing windows, fragile systems, emergency contacts, and whether destructive techniques are allowed.
3. Accounts (grey/white): dedicated test users with realistic roles, MFA arranged, and a way to reset without paging the whole company.
4. Environment (white): non-production preferred when testing exploit chains; if production is required, say so and constrain methods.
5. Remediation owners: who will fix findings in IT, your MSP or engineering.

Use our pentest preparation checklist before kickoff.

Frequently asked questions

Is grey box "cheating" compared with black box?

No. Grey box models a common real-world start: the attacker already has a low-privilege account. Black box answers a different question. Buy the question you need answered.

Can a test be black box externally and grey box internally?

Yes, and that hybrid is common. External discovery stays zero-knowledge; internal or application testing uses a standard user once that phase starts. Put both in the written scope.

Does white box mean testers only read code and never attack live systems?

Not usually. Most white box engagements still include dynamic testing against a running environment. Source code and diagrams make that testing more targeted.

Will more knowledge always find more vulnerabilities?

It usually finds more relevant issues in the same timebox, especially authz and business logic flaws. A skilled black box team can still find critical perimeter issues. Depth and realism are the trade-off, not a guarantee of a longer findings list.

Is a vulnerability scan the same as a black box pentest?

No. A scan lists potential issues automatically. A black box pentest has humans validate, chain and prove impact. See vulnerability assessment vs penetration testing.

How often should we repeat testing if we use grey box?

Many organisations retest at least annually and after major changes (new VPN, cloud migration, major app release). Frequency depends on change rate and stakeholder demand. See how often you should get a penetration test.

Who should own the testing program between engagements?

Someone has to set scope, track remediation and report upward. If you lack a security lead, a vCISO retainer can provide advisory oversight. That is advisory and oversight, not implementation or incident response.

The bottom line

Black box asks what a stranger can do. Grey box asks what a low-privilege insider or phished user can do. White box asks whether deep design and code weaknesses still hide when testers have the map. Most Australian SMBs should start grey box for authenticated depth, use black box when they need a pure outsider story, and reserve white box for high-value applications and architecture reviews. Write the knowledge level into the scope, insist on proof-of-concept evidence, and plan remediation before the report lands.

Ready to scope the right approach? Explore our penetration testing services or book a 1-on-1 scoping call with the Aussie Pentest team.

This article is general information, not legal or compliance advice. Regulatory references are current as of October 2026.

Sources

• ▸NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• ▸OWASP Top Ten
• ▸ASD's ACSC: Essential Eight maturity model
• ▸OAIC: Data breach notifications increase to all-time high in 2025
• ▸OAIC: APP Guidelines Chapter 11, Security of personal information
• ▸APRA: CPS 234 Information Security
• ▸APRA: CPG 234 Information Security