Security Solution Consultants (SSC) provides penetration testing services, secure code review and threat modelling for organisations across Australia and New Zealand. We test web applications, APIs, mobile apps, networks, cloud platforms, Microsoft 365 and operational technology, and we run phishing simulations that measure how people respond. Every engagement ends with findings your developers and engineers can act on, and a retest that proves the fixes worked.
We are based in Tarneit, Victoria 3029. Most testing is delivered remotely; we come on site for internal network testing where remote access is not practical, for OT and plant environments, and for findings walkthroughs. If you already know what you need, talk to us.
Most organisations asking for “a pen test” are really asking one of eight different questions. Matching the test to the question is the single biggest factor in whether the money is well spent.
If a customer contract, regulator or auditor is driving the request, bring the clause. It usually tells us the scope, the depth and the evidence they expect to see.
A penetration test is an authorised attempt to find and exploit weaknesses the way a real attacker would, then show how far that access goes. We test manually first and use tools to cover breadth, because the weaknesses that matter most, such as broken access control and business logic flaws, are the ones scanners miss.
Authenticated and unauthenticated testing of web applications and the APIs behind them, measured against the OWASP Top 10:2025, the OWASP Web Security Testing Guide and the OWASP API Security Top 10. We test each user role against the others, because broken access control sits at the top of the 2025 list for good reason. Where you want a defined level of assurance, we map coverage to the OWASP Application Security Verification Standard 5.0.0, released in May 2025.
iOS and Android apps tested against the OWASP Mobile Application Security Verification Standard (MASVS) using the Mobile Application Security Testing Guide (MASTG): local data storage, authentication, network communication, platform interaction and the backend APIs the app relies on.
External testing shows what an attacker on the internet can find and use: exposed services, remote access, forgotten hosts and weak authentication. Internal testing starts from the position of a compromised laptop or a malicious insider and follows the attack paths through Active Directory, file shares and flat networks. For PCI DSS we also test that segmentation really isolates the cardholder data environment.
Many serious incidents start with a misconfiguration rather than an exploit. We review AWS, Azure and Google Cloud tenancies and Microsoft 365 against CIS Benchmarks and the platform providers’ own security baselines: identity and conditional access, privileged roles, storage exposure, logging and alerting, email security and external sharing. It pairs well with EASMLens, which keeps watching your internet-facing estate between tests.
A secure code review reads your source code to find security flaws before they reach production. We combine tool-assisted analysis with manual review of the areas tools handle poorly: authentication and session handling, authorisation checks on every sensitive action, input handling and injection, cryptography and secrets in code, error handling, and third-party dependencies. Software supply chain failures are new to the OWASP Top 10 in 2025, so dependency and build pipeline risk is part of every review.
Findings point to the file and line, explain the risk in plain terms and show the fix. For teams building bespoke software, a review supports ISO/IEC 27001:2022 Annex A controls 8.25 (secure development life cycle), 8.28 (secure coding) and 8.29 (security testing in development and acceptance), and the PCI DSS expectations for bespoke and custom software.
Threat modelling asks “what could go wrong with this design?” while changing the answer is still cheap. In a short series of workshops with your architects and developers we map data flows and trust boundaries, work through threats using STRIDE (or a risk-centred approach such as PASTA where business impact needs to lead), and agree mitigations. You receive a threat register, design changes ranked by risk, abuse cases for your backlog and a focused test plan, so the later penetration test spends its time where the risk actually is.
Threat modelling is the clearest way to show customers and regulators that security was designed in rather than bolted on, which is exactly what secure by design guidance from ASD and its international partners asks software makers to demonstrate.
Energy, water, ports, mining and manufacturing run operational technology where an aggressive scan can stop a process. Our OT assessments are safety first and passive by default: network architecture and zone review, configuration review of firewalls and remote access, traffic analysis from a span port, vendor and contractor access paths, and the boundary between corporate IT and the plant. We align findings to NIST SP 800-82 Rev. 3 and the IEC 62443 series, and to the SOCI Act and AESCSF where they apply. Any active testing is agreed with operations and scheduled into a maintenance window. See also our energy sector security assessments.
Most breaches still start with a person. We run phishing simulations and, where agreed, phone and on-site social engineering tests that measure how quickly staff report a lure, not just how many click. Campaigns are designed with your HR and communications teams, nobody is named or shamed, and results feed targeted awareness training. For ongoing campaigns, see PhishLens.
Scope and rules of engagement. The assets in scope, test accounts for each role, testing windows, excluded systems and who to call if something behaves unexpectedly. Written authorisation comes before any testing.
Model and map. A short threat model or reconnaissance phase identifies the likely attack paths, so effort goes where an attacker would go.
Test. Manual testing first, tools for coverage, and chaining of smaller weaknesses into the realistic attack an individual finding would never show.
Live alerts. Critical findings are reported the same day, so you can act before the report is written.
Report and retest. Findings are rated by risk with CVSS scores and business context, evidence and reproduction steps, and fix guidance. After you remediate, we retest and issue a retest letter.
We follow documented, industry-accepted methods: the OWASP Web Security Testing Guide, ASVS 5.0.0, Top 10:2025 and API Security Top 10, OWASP MASVS and MASTG for mobile, the Penetration Testing Execution Standard (PTES) and NIST SP 800-115 for technical testing, and NIST SP 800-82 Rev. 3 and IEC 62443 for OT. Our testers hold recognised offensive security certifications such as OSCP.
We test for organisations in Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra, Hobart and Darwin in Australia, and in Auckland, Wellington, Christchurch, Hamilton, Tauranga and Dunedin in New Zealand. Each city page explains the local rules and the testing local organisations ask for most often.
At least once a year and after any significant change, such as a new application, a major release, a cloud migration or a network redesign. PCI DSS v4.0.1 sets exactly that rhythm for internal and external testing, and it is a sensible default for everyone else. Internet-facing applications that change weekly benefit from lighter, more frequent testing tied to the release cycle.
A scan uses tools to list known weaknesses. A penetration test has a person attempt to exploit and chain those weaknesses to show what an attacker could actually reach. An audit checks whether your controls exist and operate against a standard. They answer different questions, and one does not replace another.
It should not. We agree testing windows, rate limits, excluded systems and an escalation contact before we start, and we avoid destructive techniques on production unless you ask for them in writing. Where risk is high, we test a production-like staging environment and confirm the result with a light check on production.
Yes, and safety comes first. On live control networks we start passively: architecture and configuration review, traffic analysis from a span port, remote access paths and vendor connections. Any active testing is agreed with operations, scheduled for a maintenance window and limited to systems the plant owner approves.
For software you build yourself, usually yes. A penetration test sees the application from the outside in a fixed window, so it can miss flaws in paths it never reaches. A code review reads the logic directly and finds problems such as missing authorisation checks, hard-coded secrets and unsafe dependencies before they ship.
Yes. After you remediate, we retest the reported findings within an agreed period and issue a retest letter showing which issues are closed. Auditors and customers usually want that letter as much as the original report.
Cost follows scope: the number of applications, user roles, APIs, IP ranges or sites, and whether you need authenticated testing, code review or OT work. We scope first and give a fixed quote, so you know the price before any testing starts.
Tell us what you need tested and why: a customer contract, an audit, a release or an incident. We will recommend the smallest test that answers the question and give you a fixed quote.
Secure your cloud environments & ensure safe migration with compliance-ready.
Stay informed with the latest cybersecurity news and expert tips.
Copyright © 2026 Security Solution Consultants. ABN 87 616 212 063. Tarneit, Victoria 3029, Australia. All Rights Reserved.
