Vulnerability Scanning and Assessment

Vulnerability scanning and assessment is the systematic search for known weaknesses in software, configurations, and exposed services, followed by an assessment of what each weakness would mean for the firm. A scanner compares what a system actually runs against lists of known flaws and misconfigurations, then produces findings ranked by severity and by relevance. Assessment turns that raw list into decisions. A flaw in an internet facing login service for online banking matters differently from the same flaw in an isolated internal tool with no customer data. Under DORA, this work forms part of the basic testing layer, repeated as systems change, so that weaknesses are found by the firm before they are found by someone else.

Scanning finds. Assessment judges. A scan of an online banking estate might return a long list of outdated libraries, open ports, and configuration gaps. Without assessment, that list is noise, and teams either chase the loudest items or ignore the list entirely. Assessment asks where the component sits, whether it can be reached from outside, what data it touches, and whether another control already limits the damage. A high severity flaw in a component that is unreachable and holds no sensitive data may rank below a moderate flaw in a customer authentication service. That ranking, explained in plain terms, is what turns scanning into risk management.

Scans are strong on known flaws and weak on everything else. They do not reliably reveal logic errors, such as a payment approval flow that can be bypassed, or business process weaknesses, such as a privileged account shared by a whole team. They also depend on coverage. A system that is not in the asset inventory will not be scanned, and a supplier system that the firm cannot scan directly will only be understood through the supplier's evidence. A firm that treats a clean scan as proof of security is making the same error as a firm that treats a gentle test as proof of resilience. The scan answers one question well. Other testing methods in this cluster answer the rest.

A finding needs an owner, a judgement about urgency, and a date for remediation or for a documented decision to accept the risk for a stated reason. The online banking example makes the sequence concrete. A flaw in the login service is triaged by the team that owns authentication, a fix or a compensating control is applied, and the system is rescanned to confirm the fix worked rather than merely intending to work. Where a fix depends on a supplier, the firm needs the supplier's timetable and, in the meantime, a way to limit exposure. Findings that sit unowned in a report, however severe, have not been managed. They have only been observed.

Scanning a laboratory copy of a system while production runs a different version tells the firm about the laboratory, not about the service customers use. Version drift, manual changes made directly in production, and supplier updates can all leave the live system different from the tested copy. The pitfall named in this cluster, testing in conditions that never resemble production, applies directly here. Scans should therefore cover production or a faithful replica, with safeguards for live data, and the scope statement should say plainly which systems were scanned, which were excluded, and why. Gaps in scope are findings in their own right.

A useful report names the systems scanned, the date and coverage of the scan, the findings that matter for critical functions, and the status of each one. It distinguishes new findings from repeat findings, and it shows whether previous fixes were confirmed by rescanning. It also admits its limits, such as systems that could not be scanned and flaws that scanning cannot detect. A report that lists only counts, with no owners and no follow up, may satisfy a filing requirement while leaving the underlying risk untouched. The test of scanning is not the report. It is the shrinking list of important, unowned weaknesses.