What is the difference between black-box and grey-box testing?

Black-box testing starts with no credentials, source code or inside knowledge, exactly like an external attacker. Grey-box testing adds authenticated access and context so we can test deeper: what a logged-in user, or a stolen account, could reach.

Does ISO 27001 or SOC 2 require a penetration test?

Neither standard names penetration testing as mandatory, but auditors routinely expect evidence that technical vulnerabilities are identified and managed, and a recent independent pen test is the clearest evidence. Many customers ask for one directly.

Will testing disrupt our production systems?

Testing follows agreed rules of engagement and testing windows. Exploits are validated safely; we do not run destructive or denial-of-service tests unless explicitly agreed.

Penetration Testing Melbourne | Black-Box & Grey-Box

In short: Cyber Veda’s penetration tests start from an attacker’s view of your internet-facing systems and follow PTES, OWASP WSTG and NIST SP 800-115, with findings mapped to OWASP Top 10, CWE and CVSS.

Black-box vs grey-box, side by side

Unauthenticated · external

Black-box

Tests what anyone on the internet can reach.

Authenticated · deeper

Grey-box

Tests what a logged-in user, or a stolen account, can reach.

Starting point

No access and no inside knowledge. We begin where an anonymous attacker on the internet would.

Test accounts at each user role, plus enough context to test efficiently.

What you give us

Agreed scope: domains, IP ranges, applications
Rules of engagement and testing windows

Everything black-box needs
Test accounts for each role, ideally in two tenants
API documentation, such as an OpenAPI spec or Postman collection
A short walkthrough of key workflows

Who it simulates

An outsider, opportunistic or targeted, with nothing but your company name.

A malicious customer, a stolen or phished user account, or an insider with limited access.

Where we focus

Attack-surface discovery: subdomains, forgotten hosts, exposed services
Leaked secrets, public repositories and cloud storage
Login, registration and password reset
TLS, headers, misconfiguration and known CVEs

Access control and IDOR: can one user reach another’s data?
Privilege escalation between roles
Tenant isolation in multi-tenant platforms
Business logic and API authorisation
File uploads, integrations and admin functions

Typical findings

Forgotten or unmanaged assets
Exposed admin panels and services
Outdated software with known vulnerabilities
Subdomain takeover and DNS or email weaknesses

One customer viewing or changing another’s records
Ordinary users performing admin actions
Broken object-level authorisation in APIs
Workflow bypasses, such as skipping an approval step

Strengths

The most realistic picture of what is exposed today, including assets you didn’t know you had.

Much deeper coverage of the same application, and the high-impact flaws behind the login, where your data lives.

Limits

Time goes on getting past the login, so features behind it get little coverage.

Less time on discovering unknown external assets, unless paired with a black-box sweep.

Best for

Websites and internet-facing infrastructure
A first independent test
Annual external validation and insurer questionnaires

SaaS products and customer portals
APIs and multi-tenant platforms
Enterprise security reviews, SOC 2 and ISO 27001 evidence

Coverage emphasis

Realistic outsider view

Discovery of unknown assets

Coverage behind the login

Access control and data separation

Business logic

Realistic outsider view

Discovery of unknown assets

Coverage behind the login

Access control and data separation

Business logic

Which one do you need?

A website and email, but no customer login Black-box

Your exposure is what the internet can see.

Customers or staff log in to your product or portal Grey-box

The risk that matters most sits behind the login.

Selling software to enterprise customers Both

A grey-box application test with a black-box sweep of your external footprint.

Not sure? We’ll recommend the right mix in the free consultation, based on what your customers, insurer or auditor are asking for.

An attacker’s-eye view

We start with what the internet can see and work inward: domains, subdomains, DNS and email posture, historical assets, public repositories and leaked secrets, cloud storage exposure and takeover risk.

Manual depth, automated breadth

Broad reconnaissance and scanning are combined with manual validation: authentication, sessions, JWT and OAuth, access control and IDOR, injection, XSS, CSRF, SSRF, file upload, GraphQL and WebSocket abuse, TLS, headers, CORS, request smuggling and known CVEs. Real weaknesses stay in the report. Scanner noise doesn’t.

A report your team can use

Executives get a clear risk picture. Engineers get evidence, affected assets, severity and practical remediation guidance, prioritised by what matters most.

What's included

Scope and rules-of-engagement workshop
Passive OSINT, attack-surface mapping and active asset discovery
Specialist-led testing of web apps, APIs and exposed infrastructure
Safe validation and proof of exploit for confirmed weaknesses
Severity rating with likelihood, impact and standards mapping
Executive summary plus detailed evidence for remediation owners
Prioritised remediation roadmap
Coverage appendix showing every completed check
Close-out briefing for leadership and technical teams

When you'd use this

Before go-live, a major release or a material production change
For customer, insurer, investor or procurement assurance
To support ISO 27001, SOC 2 and security due diligence
After a cloud migration, architecture change or security incident
For annual independent external validation

Find the way in before an attacker does.