Penetration Testing for AU Businesses

What penetration testing means here

A Bedstone penetration test is an active, adversarial exercise on a defined scope. We attempt to compromise the system the way an attacker would: enumeration, weakness identification, exploitation, lateral movement, privilege escalation, data extraction. Every step is documented with proof-of-concept artefacts your team can reproduce, severity scored against your business context, and tied to a concrete remediation path.

What we do not do: run an automated scanner, repackage the output, and hand it back as a pentest report. Scanners are part of the toolkit, never the whole engagement. If the deliverable is a list of CVEs from a scanner you could have run yourself, it was not a pentest.

Where this fits

A penetration test is the right call when most of the following are true.

You are launching or have recently launched a customer-facing system and want exploit paths surfaced before someone else finds them.
An enterprise customer, regulator, or insurer is asking for an annual or pre-procurement pentest with an attestation letter.
You have a SOC 2, ISO 27001, IRAP, or PCI-DSS process running and need the pentest control in evidence.
You have invested in detection or response capability and want to validate whether it would actually catch a real attacker.
You have shipped a significant new system (a customer portal, a new API, a public-facing AI agent) and want it tested before it scales.
You suspect, or know, you have been targeted, and want an independent read on your exposed surface.

What we test

Scope is set per engagement. Common surfaces:

Web applications. Authentication, authorisation, session management, business logic flaws, input validation, file handling, SSRF, IDOR, race conditions, dependency exposure.
REST and GraphQL APIs. Auth flows, scope and tenancy boundaries, rate limiting, mass assignment, broken object-level authorisation, introspection exposure.
Mobile applications. iOS and Android. Local data storage, transport security, deep linking, jailbreak / root detection, binary protections, server-side API surface as exercised by the app.
Cloud configuration. AWS, Azure, GCP. IAM policy abuse, exposed buckets and blobs, network exposure, key management, lateral movement paths, escape from compromised compute.
Internal networks. Workstation to server, segmentation, Active Directory and Entra ID, Kerberos, lateral movement, privilege escalation, persistence.
External networks and perimeter. Internet-facing inventory, exposed services, fingerprinted versions, known weaknesses, unauthenticated exploitation paths.
Identity and access flows. SSO, MFA bypass, conditional access weaknesses, session hijacking, privileged access abuse, joiner-mover-leaver gaps.
Supply chain and third-party. Dependency exploitation, SaaS vendor integration risk, OAuth scope abuse, vendor-managed device exposure.
AI systems. Prompt injection, indirect prompt injection, training-data exposure, agent action boundary breakouts, model output handling, third-party model provider attack surface.
Social engineering and phishing. Targeted phishing campaigns under documented rules of engagement. Vishing where in scope.
Physical and red-team. Where in scope and signed off: tailgating, badge cloning, physical implant, full red-team engagements with no-knowledge defenders.

Methodology

We work to industry-standard methodology with Bedstone-specific additions for AI systems and AU regulatory context.

OWASP ASVS and Testing Guide. For application-layer testing. Verification at the level appropriate to the system's risk profile.
PTES (Penetration Testing Execution Standard). For network and infrastructure engagements. Documented phases from pre-engagement through reporting.
MITRE ATT&CK. For tactics, techniques, and procedures mapping in red-team engagements and post-exploitation reporting.
NIST SP 800-115. For technical guide reference and compliance alignment.
Bedstone AI testing playbook. Internal methodology for LLM and agent systems covering prompt injection (direct and indirect), training data exposure, agent boundary testing, output sanitisation failure, third-party model provider risk.
CVSS 3.1 plus business context. Severity scoring tied to your environment, not just generic CVSS in isolation. A critical CVE in a system with no real exposure is a low business risk and we score it that way.

How we work

Five-step engagement from scope to remediation re-test.

Scope and rules of engagement. Define what is in scope, what is explicitly out, allowed techniques, working hours, escalation contacts, evidence handling, data residency. Signed before any testing starts.
Pre-engagement and access. Where grey or white box: credentials provisioned at appropriate scopes, time-bounded, documented. Source code access where in scope.
Testing. Active exploitation against the agreed scope. Real-time critical-finding escalation to a named contact. Daily check-ins for engagements over one week.
Reporting and walkthrough. Full report delivered. Live walkthrough with engineering and leadership. Remediation plan agreed.
Remediation re-test. Re-verify the original findings cannot be exploited after fixes ship. Re-test report attached to the original.

Working with your IT and security team

A pentest is most useful when it strengthens the team that already owns the system. We partner with your IT, security, and DevOps people from day one. We came up as software engineers and infrastructure operators ourselves, so we speak the same language: time-bounded access at the right scopes, documented requests, no blanket admin tokens, and findings written for engineers who will own the fix.

In practice your team gets an access request with scopes spelled out, a kickoff that includes them, daily check-ins during testing, and findings they can engage with technically rather than receive as an outside verdict. We work to least-privilege, document everything we used, and hand the access back at engagement end.

What week one looks like

Most engagements run for one to four weeks. The first week sets up the rest.

Day 1. Kickoff and rules of engagement. Scope confirmed in writing. Rules of engagement signed. Escalation paths and emergency contacts agreed.
Day 2. Access provisioning. Credentials provisioned at the agreed scopes. Source access where in scope. VPN, jumpbox, or other access path tested end to end.
Day 3. Reconnaissance and enumeration. Inventory the in-scope surface. Map identity model, data flows, technology stack. Build the attack-surface picture before active testing.
Day 4. Active testing begins. Manual testing of highest-risk areas. Tooling running alongside, not in place of, manual work. First findings landing in the shared tracker.
Day 5. First findings review. 30-minute check-in covering what we have found so far, what we are about to test next, and any criticals already escalated.

What you actually receive

At engagement end you hold three things that change what your team does next.

Findings register. Every finding documented with reproduction steps, exploit proof-of-concept, blast-radius analysis, severity, exploitability, remediation, owner, and effort. Sortable, filterable, ready to import into your ticketing or GRC tool.
Remediation plan. Findings sequenced into a roadmap with effort estimates and dependencies. Your engineering manager can plan against it directly.
Executive summary. Two-page summary in plain language. What we found, what the business risk is, recommended next steps. Designed for leadership and the board, not the engineers.
Attestation letter. Where required for SOC 2, ISO 27001, IRAP, PCI-DSS, or enterprise procurement: methodology statement, scope description, summary findings, attestation that the engagement was performed.
Re-test report. After remediation, a follow-up report verifying the original findings cannot be exploited and that fixes did not introduce new weaknesses.

Bedstone pentest vs alternatives

Option	Best for	Trade-off
Big-four / large consultancy	Procurement that needs the logo. Broad coverage on paper.	Testing usually done by juniors. Report leans on automated tooling padded with framework mappings.
Offshore pentest shops	Tight budgets where the enterprise customer needs a pentest box ticked and isn't reading the report.	Light on the manual testing that finds business-logic flaws. Report is usually a CVE list from a scanner.
Automated DAST / IAST tools	Continuous coverage between engagements. Catches known vulnerabilities and obvious patterns.	Won't find business-logic flaws, custom auth weaknesses, or chained exploit paths. Necessary but insufficient.
Internal red team	Mature security teams with sustained investment. Pairs with external engagements for independence.	Requires multi-year build-out and salaries. Out of reach for most mid-market.
Bedstone pentest	Actionable output and a partner who can also help fix the findings. Manual testing across app, infra, identity, supply chain, AI.	Less brand recognition than big-four. We trade logo for findings the team can act on.

How to evaluate a partner

Ask who actually does the testing. Named seniors with verifiable backgrounds, or someone you have never met. Get LinkedIn profiles and certifications.
Ask for a sample finding from a prior engagement. Real findings have specificity: exploitation steps, blast radius, business context. Generic CVE descriptions are a tell.
Ask about the remediation path. A real pentest ties every finding to a fix. If they cannot describe what remediation looks like, the deliverable will not move your team forward.
Ask about re-testing. Re-test on remediation should be part of the engagement. If it is a separate paid add-on, the original engagement is incomplete.
Ask about AU regulatory context. Privacy Act, OAIC, AUSTRAC, IRAP, sector-specific obligations. An offshore or US-centric firm will struggle here.
Ask about AI testing. If your system includes AI agents and the partner cannot describe how they test for prompt injection or agent boundary breakouts, they will miss that whole class of finding.

Cadence and retainer options

One-off pentest before launch. Pre-launch coverage on a defined surface. Standard scope, fixed timeline. Most common engagement type.
Annual pentest. Required for SOC 2, ISO 27001, IRAP, PCI-DSS, and most enterprise procurement. Same scope or evolved scope year to year.
Quarterly checkpoint engagements. Lighter scope covering changes since the last pass. Useful for fast-moving engineering teams shipping continuously.
Per-release pentest retainer. Monthly engagement where significant releases get tested before they ship. Security keeps pace with the product.
Red-team engagement. Longer adversarial simulation with limited defender knowledge. Tests detection and response, not just preventive controls. For mature security teams.
Post-incident pentest. Targeted scope around the incident vector, plus broader posture review on systems exposed to the same class of issue.

Compliance overlay (SOC 2, ISO 27001, IRAP, PCI-DSS)

Where the engagement supports a formal compliance submission or enterprise procurement, we produce the artefacts your auditor or customer expects.

SOC 2. Common when AU SaaS businesses sell to US enterprise customers. Type 1 and Type 2 evidence. Pentest control in scope with the right methodology statement and attestation letter.
ISO 27001. Pentest evidence aligned to Annex A controls, with the methodology and scope description your assessor expects.
IRAP. Australian Signals Directorate framework for cloud and on-premise systems handling government workloads. We work alongside an IRAP assessor where one is engaged.
PCI-DSS. Pentest control for cardholder data environments. External and internal scope, segmentation testing, retest after fixes.
Sector-specific. APRA CPS 234 for regulated financial entities, ACSC Essential Eight maturity, AFSL custody and operational risk, healthcare and education sector frameworks.
Enterprise procurement. Plain-language attestation letter your enterprise customer can hand to their security team. Methodology, scope, and summary findings without exposing sensitive technical detail.

How we structure engagements

Pentests are scoped to the surface and depth required. Common shapes:

Fixed-scope engagement. Defined surface, defined timeline, defined deliverable. Most common.
Pre-launch engagement. Tighter scope on a specific system before it goes live. Faster turnaround.
Annual pentest retainer. Recurring engagement to satisfy compliance and enterprise customer requirements. Predictable scope, predictable cost.
Per-release retainer. Monthly engagement where major releases get tested before ship.
Red-team engagement. Longer, broader scope. Priced as a milestone engagement rather than a fixed-scope deliverable.

Engagements with novel testing scope (AI agents, custom protocols, internal systems with no prior testing baseline) can qualify for the R&D Tax Incentive. Reach out and we will reply within 24 hours with the shape and pricing that fits your situation.

Common questions

What is penetration testing and how is it different from a security audit?

A penetration test is an active, adversarial exercise. We attempt to break in, chain weaknesses into a real exploit, and document what an attacker would actually achieve. A security audit is a broader posture review across applications, cloud, identity, data, and process. The two often combine in a single engagement but answer different questions. Pentesting answers can someone break in. Audit answers what is the security state of the organisation.

How long does a penetration test take?

A focused web application test runs one to two weeks. A larger external network or multi-application engagement runs two to four weeks. Red-team-style engagements with social engineering and physical scope can run six weeks or more. Re-testing of remediated findings adds a few days.

Will a pentest take down our production systems?

No, by default. We work to documented rules of engagement, avoid destructive techniques in production, and coordinate any potentially disruptive testing in advance. Where production testing is not safe, we work against staging or production mirrors instead.

Do you offer black-box, grey-box, or white-box testing?

All three. Black box gives you the outside-attacker view but eats time on enumeration. Grey box, with limited credentials, tends to find more in less time. White box, with full source plus credentials, maximises depth and is the standard for pre-launch testing. We recommend grey or white box for most engagements.

Can the test support SOC 2, ISO 27001, IRAP, or PCI-DSS compliance?

Yes. We produce the artefacts in the format your auditor or assessor expects, including methodology statement, scope description, findings register, severity scoring, and attestation letter where required.

What happens if you find a critical vulnerability mid-test?

You hear the same day. Critical findings, including remote code execution, authentication bypass, and data exposure at scale, get escalated immediately with recommended containment. We do not save criticals for the final report.

Do you re-test after we fix the findings?

Yes. Re-testing of remediated findings is included in most engagements. We re-verify the original finding cannot be exploited and that the fix did not introduce a new weakness.

Do you test AI agents and LLM systems?

Yes. Prompt injection (direct and indirect), training data exposure, model output handling, agent action boundary breakouts, third-party model provider attack surface, and the operational risks of AI agents in production are all in scope where the system includes them.