Security Audits for AU Businesses

What a security audit means here

A Bedstone security audit is a structured review of your security posture across the layers an attacker actually targets: web applications, APIs, cloud configuration, identity and access management, secrets, data handling, supply chain, and operational process. The output is a prioritised list of findings, each with an exploit scenario, a recommended fix, an owner, and an effort estimate. Plus a board-ready summary the leadership team can act on.

What we do not do: vulnerability scans dressed up as audits, generic checklist reviews with no manual testing, or 200-page PDFs designed to justify the invoice instead of the findings. If the deliverable does not change what your engineers do next week, it was not an audit.

Where this fits

A security audit is the right call when most of the following are true.

You are about to launch or expand a customer-facing system and want exposure mapped before it goes live.
An enterprise customer or government procurement process is asking for evidence of security posture. SOC 2, ISO 27001, IRAP, or sector-specific.
You inherited a system from a previous team or vendor and the security state is unknown.
You had an incident, or a near-miss, and want to find what was missed and what would catch it next time.
You are scaling fast and want to find the controls that should have been built in earlier.
Your insurer, regulator, or board has asked for an independent security review.

What we audit

The full audit covers the surface area attackers target. Engagements can scope to specific layers when required.

Application security. Web applications, APIs, mobile apps. Authentication, authorisation, input validation, session management, business logic flaws, rate limiting, dependency hygiene, common OWASP and beyond.
Cloud configuration. AWS, Azure, GCP. IAM policies, S3 / blob exposure, network configuration, security groups, key management, logging, monitoring, infrastructure-as-code review.
Identity and access management. Workforce identity (Microsoft Entra, Okta, Google Workspace), customer identity, MFA enforcement, conditional access, privileged access, joiner-mover-leaver process.
Secrets and credentials. Where secrets live, how they rotate, exposure in code or repositories, third-party API key handling, customer-data tokenisation.
Data handling and classification. What data exists, where it lives, who has access, how it flows, retention, deletion, encryption at rest and in transit, data residency for AU obligations.
Supply chain and third-party. Dependencies, SaaS vendors, integration partners, the security posture you inherit from them, OAuth scopes you grant.
AI-specific risks. For systems with AI agents or LLM integrations: prompt injection, training-data leakage, model output handling, third-party model provider posture.
Operational process. Incident response, on-call, change management, vulnerability management, patching cadence, backup and disaster recovery.
Human factors. Phishing exposure, social engineering, internal security culture, security training cadence.

How we work

Five-step engagement from intake to remediation handover.

Scope and prep. Define audit boundaries, get access provisioned at appropriate scopes, schedule interviews, set rules of engagement.
Discovery. Inventory the systems, identities, data flows, and processes in scope. We build the map before we test.
Testing. Manual review plus tooling. Application testing against documented and undocumented flows. Cloud configuration review. Identity policy review. Code review where relevant.
Findings and prioritisation. Every finding documented with exploit scenario, severity, exploitability, remediation, owner, and effort. Severity scores tied to your business context, not generic CVSS in isolation.
Handover. Live walkthrough of findings with the engineering and leadership teams. Remediation plan agreed. Optional retainer for re-test after fixes.

Working with your IT and security team

An audit is most useful when it strengthens your existing security team rather than blindsiding them. We partner with your IT, security, and DevOps teams from day one. We speak their language because we came up as software engineers and infrastructure operators ourselves: read-only credentials at the right scopes, documented access 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, an audit kickoff that includes them, and findings they can engage with technically rather than receive as an external verdict. We work to least-privilege scopes, document what we use, and hand the access back at engagement end.

What week one looks like

Most audits run for two to four weeks. The first week sets up the rest.

Day 1. Kickoff and scope confirmation. Boundaries agreed, rules of engagement signed, key contacts mapped, communication channels established.
Day 2. Access provisioning. Read-only access provisioned at appropriate scopes to systems in scope. Documented and time-bounded.
Day 3. Discovery interviews. 30 to 45 minute conversations with engineering, IT, security, ops. Understand the system as the operators see it before we test it.
Day 4. Inventory and mapping. System inventory built, data flows mapped, identity model documented, attack surface enumerated.
Day 5. Testing kickoff. Manual review begins on the highest-risk areas surfaced in discovery. Findings start landing in the tracking system you and we share visibility into.

What you actually receive

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

Findings register. Every finding documented with exploit scenario, severity, exploitability, remediation, owner, and effort. Sortable, filterable, ready to import into your existing ticketing or GRC tool.
Remediation plan. Findings sequenced into a remediation roadmap with effort estimates and dependencies. Your engineering manager can plan against it directly.
Board-ready summary. Two-page executive summary in plain language. Critical findings, risk posture, recommended next steps. Designed for the leadership team and the board, not the engineers.
Optional artefact set for compliance. Where the audit supports a SOC 2, ISO 27001, or IRAP submission, we produce the evidence artefacts in the format your auditor expects.
Re-test on remediation. Optional follow-up engagement to verify fixes against the original findings. Cleaner than a fresh audit.

Bedstone audit vs alternatives

Option	Best for	Trade-off
Big-four / large consultancy	Procurement that needs the logo. Broad framework coverage on paper.	Slower, more expensive. Actual testing often done by juniors with limited engineering depth.
Specialist boutique pentest firm	Deep adversarial testing on a specific application or attack surface.	Less suitable for organisation-wide posture audits across apps, cloud, identity, process, and supply chain.
Automated scanning tools	Continuous coverage on known vulnerabilities and obvious misconfigurations.	Will not surface business-logic flaws, custom-IAM weaknesses, or human-factor risk. Necessary but insufficient.
Bedstone audit	Actionable findings and a partner who can also help fix them. Senior engineers across the full posture.	Less brand recognition than big-four. We trade logo for output.

How to evaluate a partner

Ask who actually does the testing. Named seniors, or someone you have never met. Get LinkedIn profiles.
Ask for a sample finding from a prior audit. Real findings have specificity. Generic findings are a tell.
Ask about the remediation path. A real audit ties every finding to a fix. If they cannot describe what remediation looks like, the deliverable will not move your team forward.
Ask about AU regulatory context. Privacy Act, OAIC, AUSTRAC, IRAP, sector-specific obligations. An offshore or US-centric firm will struggle here.
Ask whether they can re-test after fixes. A partner who can verify remediation closes the loop. One that cannot leaves you guessing whether the fix worked.

Audit cadence and retainer options

One-off audit before a launch. Pre-launch coverage to find what would have shipped broken. Standard scope, fixed timeline.
Recurring annual audit. For organisations with compliance obligations or board-driven security posture reviews.
Quarterly checkpoint audits. Lighter cadence covering changes since the last pass. Useful for fast-moving engineering teams.
Post-incident audit. Find what was missed, what would catch it next time, and what other systems are exposed to the same class of issue.
Embedded security partner retainer. Monthly engagement with a senior security engineer covering architecture reviews, threat modelling, vendor risk assessments, and engineering-level coaching.

Compliance overlay (SOC 2, ISO 27001, IRAP)

Where the audit supports a formal compliance submission, we produce the artefacts and evidence trail your auditor or customer expects. The audit can map directly to:

SOC 2. Common when AU SaaS businesses sell to US enterprise customers. Type 1 and Type 2 readiness work.
ISO 27001. Common in enterprise procurement, public sector tenders, and regulated industries. Statement of Applicability support, control mapping, evidence collection.
IRAP. Australian Signals Directorate framework for cloud and on-premise systems handling government workloads. We work alongside an IRAP assessor when one is engaged.
Sector-specific. AFSL, APRA CPS 234, ACSC Essential Eight, healthcare data obligations, education sector frameworks.

We work alongside your existing GRC tooling instead of replacing it. The audit feeds your evidence trail; your compliance team owns the submission.

How we structure engagements

Audits are scoped to the specific surface and depth. Common shapes:

Fixed-scope audit. Defined surface, defined timeline, defined deliverable. Most common engagement type.
Pre-launch audit. Tighter scope before a specific system goes live. Faster turnaround.
Embedded security retainer. Monthly senior security engineering capacity. Ongoing architecture reviews, threat modelling, incident response support.
Post-incident audit. Targeted scope around the incident, with optional broader posture review.

Audit work qualifies for the R&D Tax Incentive where the engagement involves novel security work on AI agents, custom integrations, or in-house systems. Reach out and we will reply within 24 hours with the shape and pricing that fits your situation.

Common questions

Is a security audit the same as penetration testing?

Different but related. A security audit is broader: posture review across applications, cloud, identity, data, process, supply chain. Penetration testing is a specific technique within that audit (or as a standalone engagement) focused on actively trying to break in. We offer both as separate Bedstone services and they often combine in a single engagement. See penetration testing for the specifics.

How long does a security audit take?

Most audits run two to four weeks for the testing and findings phases. Larger or multi-system engagements run longer. Pre-launch audits with tight scope can run in a single week.

Will the audit disrupt our production systems?

No, by default. Audits are non-destructive and use read-only access at appropriate scopes. Where intrusive testing is in scope (penetration testing, social engineering, red-team work), it is planned, rules of engagement are signed, and impact is bounded.

Can the audit support a SOC 2 or ISO 27001 submission?

Yes. We produce evidence artefacts in the format your auditor expects and map findings to control frameworks where required.

What if you find a critical vulnerability mid-audit?

You hear immediately. Critical findings get escalated the same day with recommended containment steps. We do not save them for the final report.

Can you help fix the findings, not just identify them?

Yes. Remediation can run as a separate engagement (we build the fix) or as advisory (we coach your team through the fix). Common for clients who want continuity between audit and remediation.

Do you cover AI-specific security risks?

Yes. Prompt injection, training-data exposure, third-party model provider posture, agent action boundaries, and the operational risks of AI agents in production are all in scope when the system includes them.