Guide · Melbourne
A practical security checklist before you pay for a penetration test
- security
- compliance
- checklist
- risk
Pen tests find real issues—but Melbourne SMBs save money and stress by fixing basics first. A calm checklist for web apps, admin tools, and customer data.
Penetration testing is valuable when scoped—not as a first step
A penetration test simulates focused attack paths against defined surfaces: your public app, APIs, admin tools, or cloud configuration. It is not a magical certificate that makes risk disappear, and it is not a substitute for MFA on your email.
Teams get the most from a test when obvious doors are already closed. Otherwise you pay to hear that admin/password123 works—which you could have learned for free. This checklist is deliberately calm: no fear slides, just sensible hygiene.
What a pen test is—and is not
Is: a skilled tester probes within agreed rules of engagement, documents reproducible findings, and ranks severity so developers can patch in order.
Is not: full compliance attestation for PCI or HIPAA by itself, a guarantee attackers will never succeed, or a replacement for secure design when you are still architecting.
Access and identity
- MFA on email, DNS, hosting, Stripe, CRM, and any shared admin consoles—not only executives.
- No shared root passwords in Slack DMs; break-glass accounts documented and rare.
- Offboarding checklist disables SaaS access the same day someone leaves.
- Role separation: marketing does not need production database credentials.
Applications and APIs
- Dependency and framework updates on a cadence; critical CVEs patched out of band.
- Secrets not in frontend bundles or public repos; webhook signing secrets rotated after staff changes.
- Staging data should not be full production PII unless strictly controlled.
- Rate limits and auth on admin APIs—not only customer-facing routes.
Internal tools and sprawl
Retool-style dashboards and internal Zap chains are attack surface the public never sees—attackers who phish an ops login still see them. If your integration map looks like connected tools sprawl, each connector is a door. That does not mean remove tools; it means govern access and logging.
This checklist will not replace a scoped penetration test; it makes the test about subtle flaws instead of baseline hygiene.
Backups and people
- Restore test once: prove you can recover a file or database snapshot on a timetable you are willing to tell a customer.
- Incident phone tree: who declares, who comms, who patches.
- Vendor MFA defaults: many breaches start at an email forwarder or old contractor account.
When a pen test is the right next step
Enterprise customers asking for evidence, handling sensitive data at material scale, material change after an incident, or preparing a major launch are good triggers. If three or more critical checklist items are unknown or “probably fine,” fix or document them first—you will get a tighter, more actionable report.
What good findings look like
You want ranked severity, clear reproduction, and remediation hints your developers can schedule—not a hundred-page PDF where everything is “medium.” That philosophy matches how I describe penetration testing on the security service page: exploitable issues and practical next steps, not theatre.
When to get help
If you cannot complete the checklist with confidence, or a customer mandate has a deadline, engage someone for either guided hardening or a scoped test. Bring your architecture diagram and integration list—you will spend less time on discovery and more on results.
- MFA enforced on all admin paths we identified.
- No production secrets in client-side code or public repos.
- We tested a restore from backup within the last quarter.
- We know which integrations touch customer PII and who owns their logs.