Zero-day attacks can be devastating, but zero-days are hard to come by. It is far cheaper for an attacker to exploit known, unpatched vulnerabilities than to invest in zero-day research, and vulnerability scanning finds those weaknesses first.
years testing for government and enterprise
CREST-accredited through CREST ANZ
We provide scanning as a managed service and as the first phase of our penetration testing engagements.
Our testers analyse every scan in context: removing false positives, assessing actual exploitability and providing prioritised remediation guidance for your environment.
A vulnerability scan uses automated tools to check systems against a continuously updated catalogue of known vulnerabilities (CVEs). Each finding is given a severity rating using the Common Vulnerability Scoring System (CVSS), producing a list of potential weaknesses ranked by criticality. The output is a point-in-time snapshot of your attack surface against currently known vulnerabilities.
Scanning identifies whether a known vulnerability is present. Penetration testing confirms whether it can be exploited, and what happens if it is.
missing patches and outdated software
weak or default credentials
exposed management interfaces
TLS configuration weaknesses and missing security headers
NIST SP 800-115 draws the line: scanning is automated identification, while penetration testing involves active exploitation by a skilled tester. A scan alone does not confirm whether a finding can be exploited in your environment. Two organisations with the same CVE can face very different risk, depending on their network segmentation and existing controls, which is why we pair every scan with manual analysis.
We do not deliver raw scanner output. Scanning runs as a continuous managed service with regular reporting, or on demand for a compliance obligation or project milestone. Either way, every result is analysed by the same testers who perform our penetration tests.
We agree the target systems, scanning windows and any constraints, such as production uptime requirements or change control processes.
Scans use industry-standard tooling configured for your environment. They can be authenticated, to assess internal configuration, or unauthenticated, to show what an external attacker sees.
Our testers review every finding by hand. False positives are removed, and findings are validated against your architecture and controls.
Each confirmed vulnerability gets a risk rating that accounts for exploitability, exposure and business context, rather than relying on the CVSS base score alone.
You receive a prioritised list of confirmed vulnerabilities with clear remediation steps, expected effort, and references to the relevant advisories and patches.
Scanners report what might be wrong. Our testers decide what matters in your environment.
Every result is reviewed against your environment and threat profile, prioritised by actual exploitability, segmentation, compensating controls and business impact rather than CVSS score alone. You get clear remediation guidance, not thousands of CVEs to work through.
Scanning is the first phase of every dotSec penetration test. Standalone scanning clients get the same methodology and testers, who recognise when individually low-risk findings chain into a more significant exploitation path.
Choose continuous managed scanning with scheduled scans and regular reporting, or an ad hoc engagement for a project, pre-audit preparation or post-change verification. Managed clients get a historical baseline that tracks remediation progress and shows regressions.
Our scan reports are structured to serve directly as compliance evidence, which reduces the effort needed to demonstrate conformance at audit time.
Requirement 11.3.1 requires internal vulnerability scans at least once every three months, with rescans until high-risk and critical vulnerabilities are resolved. Requirement 11.3.2 requires quarterly external scans by an Approved Scanning Vendor (ASV) (PCI SSC document library).
Annex A control A.8.8 (Management of technical vulnerabilities) expects vulnerabilities to be identified and evaluated on an ongoing basis. Regular scanning provides the evidence.
The patching strategies use a vulnerability scanner to find missing patches, at frequencies set by the maturity level (ASD patching guidance).
Requires APRA-regulated entities to maintain information security controls and test their effectiveness. Regular scanning gives evidence for both.
For organisations running a security operations function, vulnerability data also gives context for SOC, SIEM and EDR monitoring and alert triage, and findings feed into penetration test scope and risk register updates.
A vulnerability scan identifies known weaknesses using automated tools. A penetration test goes further: a tester verifies findings by hand, attempts exploitation and assesses real-world business impact. We usually run scanning as the first phase of a penetration test, and also offer standalone scanning as a managed service. NIST SP 800-115 sets out the distinction.
It depends on your regulatory context and risk appetite. PCI DSS requires quarterly internal scans by a qualified internal or external resource, and quarterly external scans by an Approved Scanning Vendor (ASV). ISO 27001 and the Essential Eight treat scanning as part of continuous vulnerability management. At a minimum, scan after any significant change, such as a new application release or major infrastructure change.
Internal and external network infrastructure, web applications, cloud environments (AWS, Azure and GCP), wireless networks and endpoints, with authenticated or unauthenticated scans. External scans for PCI DSS must be performed by an Approved Scanning Vendor (ASV); we can help you set up and review those scans with an ASV.
No. Automated tools handle discovery and initial identification. Analysis, false positive removal, contextual risk assessment and remediation guidance are done by hand by our testers. Automated output without expert analysis produces noise, not actionable findings.
For specific controls, yes. For broader frameworks such as ISO 27001 or the Essential Eight patching strategies, scanning is one part of a vulnerability management programme. For PCI DSS, Requirement 11.3.1 requires quarterly internal scans plus rescans until high-risk and critical vulnerabilities are resolved and a clean scan is obtained.
If you need a vulnerability scan as a standalone exercise, for a compliance obligation or as the first step towards a penetration test, dotSec can scope an engagement to match.
Not sure whether you need a scan or a penetration test? We can advise based on your environment and compliance obligations.
