Aussie Pentest
Book Now
How to Prepare for a Penetration Testing Engagement: Australian SMB Checklist

How to Prepare for a Penetration Testing Engagement: Australian SMB Checklist

Preparing for a penetration test means locking scope, access, and rules of engagement before testers start — not hoping a scan PDF will satisfy your board, insurer, or buyer. Use this Australian SMB checklist to get ready without wasting the engagement.

AussiePentest

AussiePentest

Preparing for a penetration testing engagement means deciding what will be tested, who owns the systems, what access testers need, and how findings will be received — before the first scan or exploit attempt. Australian SMBs that skip this work usually get a report that looks technical but is hard to action, easy to dispute with an MSP, or unsuitable for insurance and tender evidence. This checklist covers scoping, depth (automated assessment versus human-led pentest), access and rules of engagement, stakeholder briefing, and how to turn findings into usable evidence.

It complements our guides on penetration testing costs for Australian SMBs, what a pentest report should contain, and how to choose a provider. It does not replace ACSC or ASD advice — verify scope decisions against cyber.gov.au and your own contracts.

What does preparing for a pentest actually mean?

Preparation is the work that makes a penetration test actionable: clear scope, authorised access, agreed rules of engagement, and a path for remediating findings — not "install a scanner the week before." A pentest exercises real attack paths against agreed targets under controlled conditions. A vulnerability scan or automated assessment lists potential issues without the same human validation, exploitation judgement, or business-context narrative. Confusing the two is the most common preparation failure we see.

In practice, preparing means answering four questions in writing:

  1. Why are we testing? Insurance renewal, customer questionnaire, board assurance, pre-release of a web app, or Essential Eight uplift evidence.
  2. What is in scope? External IP ranges, web apps/APIs, internal network, cloud tenancy, or a mix.
  3. How deep do we need? Automated security assessment for coverage and triage, or human-led pentest for validated exploit paths and a report buyers trust.
  4. Who will fix what we find? Internal IT, MSP, developer, or a mix — with named owners before the kickoff call.

If you cannot answer those, pause the booking and run a short discovery call first. Money spent on an unscoped engagement rarely buys cleaner evidence later.

What information should you gather before scoping?

Before you talk dollars or dates, gather an asset inventory, business purpose, known constraints, and who can authorise testing. Testers cannot invent your environment. Incomplete inventories produce incomplete scope — and incomplete scope produces findings that miss the systems your buyer actually cares about.

Collect, at minimum:

  • ▸Business driver and deadline — insurer questionnaire date, tender due date, go-live, or board pack.
  • ▸Asset list — public domains, IP ranges, key SaaS apps, cloud accounts (AWS/Azure/GCP), VPN endpoints, and critical internal systems if internal testing is on the table.
  • ▸Ownership map — who owns each environment (you, MSP, SaaS vendor, co-located developer). Note anything you cannot authorise without a third party.
  • ▸Change freezes and peak periods — end-of-month finance runs, payroll windows, retail peaks.
  • ▸Existing recent testing — last scan, VA, or pentest (date, scope, and whether criticals were closed). Useful context; not a substitute for this engagement.
  • ▸Compliance hooks — Essential Eight expectations, ISO questions, customer security schedules. See Essential Eight vs ISO 27001 if you are mixing frameworks.

Also pull any written authorisation requirements from your MSP contract or cloud shared-responsibility docs. Many Australian SMBs discover mid-scoping that the "company website" is on a shared host they cannot test without the provider's written OK.

How do you decide scope (external, web/API, internal, cloud)?

Scope should match the risk question you are trying to answer — not a laundry list of every IP you own. External perimeter testing answers "what can an unauthenticated attacker on the internet see and abuse?" Web and API testing answers "can someone abuse our application logic, auth, or data?" Internal testing answers "what happens after a foothold on the LAN or after phishing?" Cloud tenancy reviews answer "are IAM, storage, and control-plane misconfigurations exposing us?"

A practical way to choose:

  • ▸Customer or insurer asking about internet exposure → start with external + primary web apps.
  • ▸Shipping or rewriting a customer-facing app → web/API focused, with staging or production rules agreed in writing.
  • ▸MSP-managed estate with lateral-movement concern → consider authenticated internal or hybrid once external hygiene is understood.
  • ▸Heavy Azure/AWS use with unclear IAM → include cloud configuration review in scope, or run it as a separate assessment if pentest days are limited.

Write scope as inclusions, exclusions, and assumptions. Exclusions matter as much as inclusions: third-party SaaS you cannot test, production databases you will not allow destructive testing against, or shared hosting out of bounds. For web apps, name the OWASP-relevant concerns you care about (auth, access control, injection) and point testers at OWASP resources if you want a shared vocabulary — without pretending a checklist replaces skilled testing.

If you are still deciding between a vulnerability assessment and a true pentest for that scope, read vulnerability assessment vs penetration testing.

How do you choose depth: automated assessment vs human-led pentest?

Choose depth based on the evidence bar you need: automated assessments are for broad technical triage; human-led penetration tests are for validated attack paths and a narrative report. An automated security assessment (Aussie Pentest tiers from $80 / $200 / $500 / $2,000) is not a penetration test. It is faster and cheaper coverage for finding obvious exposures, prioritising patching, and deciding whether a full engagement is warranted. Calling a scan a "pentest" in an insurance or tender pack is a credibility problem waiting to happen.

Use this rule of thumb:

  • ▸Need: Quick external hygiene check / triage
  • ▸Better fit: Automated security assessment
  • ▸Need: Board or buyer wants validated exploit paths
  • ▸Better fit: Human-led pentest (from $5,000 / $12,000 / $20,000 depending on scope)
  • ▸Need: Essential Eight maturity evidence
  • ▸Better fit: Essential Eight assessment ($4,950 + GST for ≤50 seats) — different artefact from a pentest
  • ▸Need: Ongoing advisory on prioritisation
  • ▸Better fit: vCISO retainer ($2,500 / $4,250 / $6,500 per month) — advisory only, not IR or implementation

For a deeper comparison of methods, see automated vs manual penetration testing. Many SMBs wisely run an automated assessment first, remediate the obvious, then book a human-led pentest so high-severity findings are not drowned out by noise.

What access, accounts, and rules of engagement do testers need?

Testers need written authorisation, the right technical access for the agreed scope, and explicit rules about what they may and may not do. Without that, testing is either illegal, ineffective, or both. Rules of engagement (RoE) should cover testing windows, rate limits, out-of-bounds systems, emergency contacts, data handling, and whether social engineering or denial-of-service style tests are allowed (usually they are not for SMB engagements unless explicitly bought).

Prepare before kickoff:

  • ▸Letter of authorisation signed by someone with authority over the in-scope assets (and MSP/cloud co-sign if required).
  • ▸Technical contacts — primary and after-hours for urgent issues.
  • ▸Accounts / credentials if authenticated testing is in scope (test users at relevant privilege levels; never share personal admin passwords in chat without a secure channel).
  • ▸VPN or jump access for internal testing, with MFA as you would for a staffer.
  • ▸Staging vs production decision documented — and if production, clearer constraints on destructive actions.
  • ▸IP allowlists so WAF/CDN/MSP monitoring does not silently block the tester's ranges.

Agree how credentials and reports will be shared and destroyed. Treat the report as sensitive: it describes how to hurt you. Align retention with your own data-handling policy and any customer NDAs.

How should you brief stakeholders and your MSP?

Brief stakeholders early so findings do not arrive as a surprise blame exercise. The people who need a heads-up are usually: business owner or exec sponsor, IT/security lead, MSP account manager, developers responsible for in-scope apps, and sometimes legal or insurance brokers if the engagement is for a renewal pack.

A short briefing pack should cover:

  • ▸Dates and windows so monitoring teams do not treat tester traffic as an incident (unless you want that as a detection test — say so explicitly).
  • ▸Scope summary in plain English for non-technical owners.
  • ▸MSP role — access provisioning, change freezes, who remediates firewall and infra findings.
  • ▸Comms path for critical findings mid-test (phone + email, not only a ticket).
  • ▸What "done" looks like — report delivery, walkthrough meeting, retest options if purchased.

Australian SMBs often under-brief the MSP. That produces delayed access, blocked IPs, and disputes over who owns remediation. Put MSP obligations in the same email thread as the authorisation letter.

What should you prepare so findings become usable evidence?

Usable evidence means findings mapped to owners, severity understood in business terms, and artefacts you can show an insurer, board, or buyer without rewriting the report. Preparation here is mostly organisational: decide who will triage, who will patch, and how you will track closure. The technical quality of the report still matters — see what to expect in a penetration testing report — but a brilliant report with no owner still fails.

Before the report lands, set up:

  • ▸A simple tracker (ticket project or spreadsheet) with columns for finding ID, severity, owner, due date, status, and evidence of fix.
  • ▸Severity language you will use with the board (critical/high/medium/low) and what "accept risk" means if you cannot fix immediately.
  • ▸Retest plan if you bought one, or a follow-up automated assessment for verifying closures on external issues.
  • ▸Evidence folder for insurers/tenders: executive summary, scope statement, dated report PDF, and closure notes — not raw exploit scripts shared casually.

Do not invent SLAs you cannot meet. Prefer honest timelines over aspirational ones that collapse when the MSP's next change window is six weeks out.

Common preparation mistakes Australian SMBs make

The mistakes that waste pentest budget are almost always organisational, not technical. Fixing them costs little compared to re-running an engagement.

Watch for these:

  1. Calling a scan a pentest in questionnaires — damages trust when a buyer asks for methodology.
  2. Scope that is "everything" — dilutes days across too many targets; critical apps get shallow coverage.
  3. No authorisation from the MSP or host — testing delayed or cancelled mid-window.
  4. Production-only testing with no RoE — either testers are too cautious to find real issues, or someone breaks a fragile system without an agreed safety net.
  5. No remediation owners named — report sits in email for months; insurer asks again next year.
  6. Testing the week before a tender deadline — leaves no time to fix or even to write a coherent response.
  7. Hiding known issues from testers — wastes time rediscovering what you already know instead of validating the paths that matter.
  8. Expecting Essential Eight maturity from a pentest alone — different question; use an Essential Eight assessment when maturity evidence is the goal.

ASD's Essential Eight and related guidance on cyber.gov.au remain the reference for maturity programs. A pentest can support risk conversations; it does not replace control-by-control maturity scoring.

What should you do next?

If your scope and authorisation are clear and you need validated attack-path evidence, book a human-led penetration test; if you first need a cheap, honest look at external exposure, start with an automated security assessment. Aussie Pentest keeps the line sharp: automated assessments at $80 / $200 / $500 / $2,000 are scans and triage — not pentests. Human-led pentests start from $5,000 / $12,000 / $20,000 depending on scope. Essential Eight assessments are $4,950 + GST (≤50 seats). vCISO retainers at $2,500 / $4,250 / $6,500 per month are advisory only.

Use this page as your pre-engagement checklist, pair it with provider selection and cost expectations, then talk through scope before anyone runs a tool. Preparation is the cheapest part of a good engagement — and the part that decides whether the report is shelf-ware or evidence you can stand behind.