Vulnerability scanning

Vulnerability scanning is the authorized, automated checking of your systems for known weaknesses: missing patches, outdated software, risky settings, exposed services and expired certificates. It covers your public internet addresses and websites, your internal network, servers, laptops and cloud accounts, and it produces a ranked list of what to fix, followed by rescans that confirm the fixes worked. It is for owners, IT managers and operations leads who want to know, on a regular schedule, where their known gaps are and in what order to close them. Canada Create is a Toronto agency at 126 Willowdale Avenue serving organizations across Canada, and vulnerability scanning sits within our cyber security practice.

Contents

• What vulnerability scanning is for
• Scope and written authorization
• External scans of IP ranges and websites
• Internal networks, servers, laptops and cloud accounts
• Authenticated and unauthenticated scans
• Ranking findings by business risk
• Reports for owners and for IT
• Fix tracking, rescans and recurring schedules
• Scanning, penetration testing and audits
• Card payments and privacy rules
• How a scanning engagement runs
• What vulnerability scanning costs
• Questions to ask a scanning provider
• Your next step

What vulnerability scanning is for

Software makers publish weaknesses in their products every week, along with the updates that fix them. A vulnerability scan compares what is running on your systems with that public knowledge and lists every match: a firewall on old firmware, a web server answering on a port it should not, a laptop missing a browser patch, a cloud storage folder open to anyone with the link, a certificate about to expire.

What owners and IT managers are usually after

Searches for “vulnerability assessment” or “external vulnerability scan” tend to come from a specific prompt. A client’s vendor questionnaire asks when the last scan was run. A card processor asks for a passing scan. The insurer wants evidence of regular checks. An IT manager suspects patching has slipped but cannot prove where. Or the owner simply wants an outside view of what the organization exposes to the internet.

Scanning versus assessment

The terms overlap. A scan is the automated check itself. A vulnerability assessment wraps the scan in human work: agreeing scope, reviewing results, removing false positives, judging which findings matter to this organization, and writing the report. Scans alone produce long lists; an assessment turns the list into decisions.

Scope and written authorization

Every engagement begins by agreeing what will be scanned and getting written permission to scan it. We only scan systems the client owns or has written authorization from the system owner to test.

Agreeing the scope

Scope lists the public IP addresses and ranges, the website and web application addresses, the internal network ranges, the servers, the groups of laptops and desktops, and the cloud accounts to be included. It also lists what is excluded, such as a fragile piece of lab equipment or a system run by a vendor who has not agreed to scanning.

Third party systems

Hosted websites, cloud services and vendor managed systems may need their provider’s permission before they are scanned. Some providers publish their own rules for customer testing; others ask for a request in advance. The scope document notes which permissions were obtained and from whom.

Timing and contacts

The authorization also sets scanning windows, names a contact on each side, and states what happens if a scan appears to be affecting a system. Most scans are light, but an old printer or a line of business application can react badly to being probed, so the first run of any new scope is scheduled with care.

External scans of IP ranges and websites

An external scan looks at your organization from the internet, the way any outside party could. It checks your public IP addresses for open services, the software versions those services reveal, weak encryption settings, and known weaknesses in what is listening.

What external scans commonly turn up

• A remote desktop or file sharing service reachable from the internet that was meant for internal use.
• A firewall or VPN appliance on firmware with published weaknesses.
• A camera system or building controller with its login page open to the world.
• Old test websites or subdomains nobody remembers setting up.
• Mail and web servers offering outdated encryption.

Website and web application scans

Websites get their own checks: the content management system and plugin versions, server software, missing security headers, exposed admin pages, directory listings and common web application weaknesses. For a WordPress or ecommerce site, findings often point at plugins that need updating or removing. Fixing those usually falls to whoever maintains the site; our website maintenance and security team handles that work for sites we look after.

Internal networks, servers, laptops and cloud accounts

Internal scans run from inside the network and see what an insider, or anyone who gained a foothold, would see. They usually find far more than external scans, because internal systems are rarely hardened to the same degree.

Servers and network devices

Internal scans check file servers, domain controllers, database servers, switches, printers, storage devices and phone systems for missing patches, default credentials, unnecessary services and unsupported operating systems. They often surface the forgotten machine under a desk that still runs an old system for one piece of software.

Laptops and desktops

Workstation scans show which machines are behind on operating system and application updates, which run software no longer supported by its maker, and which have risky settings. Because laptops travel, agent based scanning, where a small program on each machine reports its own status, is often used so devices are checked even when they are away from the office.

Cloud accounts

Cloud scanning reads the configuration of cloud services against known risky settings: storage open to the public, admin accounts without a second sign-in step, logging switched off, old access keys still active. Fixing cloud settings is part of our cloud security hardening work; the scan tells you where to start.

Authenticated and unauthenticated scans

This is one of the most important choices in a scanning engagement, and one of the least explained.

Unauthenticated scans

An unauthenticated scan probes systems from the outside without signing in. It sees what is exposed: open ports, service banners, versions a service announces about itself. It is the right view for external scans, because it matches what an outsider sees, but on internal systems it misses a great deal.

Authenticated scans

An authenticated scan signs in to each system with a dedicated, read only account and inspects it from within: installed software and exact versions, missing patches, local settings and configuration weaknesses. It produces more accurate findings and far fewer guesses. The scanning account is created in your environment, limited to what the scan needs, stored securely and disabled when the engagement ends.

Which to use

Many organizations benefit from unauthenticated external scans plus authenticated internal scans. Skipping authentication internally is a common reason a report looks reassuring while laptops are actually well behind on patches.

Ranking findings by business risk

A first scan of a small organization can produce hundreds of findings. Working through them in the order the scanner lists them wastes effort on items that do not matter while serious ones wait.

Severity scores are a starting point

Each finding carries a severity score on a standard public scale, based on how a weakness could be used and what it could affect in general. The score does not know your business. A high score on an isolated test machine may matter less than a medium score on the server that holds client files and faces the internet.

Questions that change the order

• Is the affected system reachable from the internet, or only from inside?
• Does it hold or reach personal information, financial records or client data?
• Is the weakness known to be actively used by attackers?
• Is there a fix available, and what does applying it involve?
• Is another control, such as a firewall rule or segment, already reducing the exposure?

Grouping by fix

Many findings collapse into a few actions. Forty findings across a group of laptops may all close with one browser update. Twelve findings on a server may disappear when an old service is switched off. Reports group findings by the action that fixes them, so the fix list is short even when the finding list is long.

Reports for owners and for IT

Owners and technicians need different things from the same scan, so the report has two layers.

The owner summary

The summary page says in plain language what was scanned, what stands out, the small number of actions that matter most, who should take them, and how the picture compares with the previous scan. It avoids counting findings as a measure of safety, because counts rise and fall with scope and do not reflect business risk.

The technical detail

Behind the summary, IT receives each finding with the affected system, evidence, the published reference, the recommended fix and any notes on false positives. Findings are exported in a form the IT team or provider can load into their own ticket system.

Evidence for third parties

When a client, insurer or card processor asks for proof of scanning, a short letter style summary of scope, dates and status can be shared without handing over the detailed findings.

Fix tracking, rescans and recurring schedules

A scan that is never followed up only documents the problem. The value comes from tracking fixes and confirming them.

Tracking each fix

Each action in the report has an owner, a target date the organization sets, and a status. Some findings are accepted as known risks with a written reason, such as an old system that will be replaced next quarter and has been isolated meanwhile. Accepted risks are reviewed each cycle rather than forgotten.

Rescans

After fixes are applied, the affected systems are rescanned to confirm the weakness is gone. Rescans also catch fixes that only half worked, such as a patch installed but awaiting a restart that never happened.

Recurring schedules

New weaknesses are published constantly, so a scan is a snapshot. Recurring scans, set on a schedule that suits the organization, show whether things are improving and catch new exposures, such as a service opened for a vendor and left on. Scans are also worth running after significant changes, such as a new firewall, a new website or an office move.

Scanning, penetration testing and audits

These three are often confused, and each answers a different question.

Vulnerability scanning

Scanning asks: which known weaknesses exist across our systems right now? It is broad, automated, repeatable and suited to a regular schedule.

Penetration testing

A penetration test asks: could a skilled person actually get in, and how far could they go? A tester chains weaknesses together, tries misconfigurations and logic flaws a scanner cannot judge, and shows what is reachable. It is deeper, narrower and done less often. See our penetration testing page for how that work is scoped.

Security audit

An audit asks: how does the whole organization measure against good practice, including policies, people, backups and access as well as technology? A security audit with a scored gap report may recommend scanning as one of its actions.

Related work

Scan findings often lead into other projects: firewall and segment changes, covered on our new Network security page, and device protection and patching, covered on our new Endpoint security page. Where findings point at staff habits, such as reused passwords, staff security training addresses the cause.

Card payments and privacy rules

Scanning supports several obligations organizations already have. A few are worth knowing in general terms.

Card payments and PCI DSS

Businesses that accept cards follow PCI DSS, the card industry’s security standard, which includes requirements for regular vulnerability scanning of systems connected to card payments. Which scans a merchant needs depends on how it takes payments and what its payment processor or bank asks for. Our PCI and privacy compliance page covers the wider standard.

Privacy law

Dated scan reports and a fix tracker form part of an organization’s record of the safeguards it kept. That record matters because PIPEDA expects an organization to notify the federal Privacy Commissioner and the individuals involved when a breach of security safeguards poses a real risk of significant harm, and to keep records of all breaches. For Quebec operations, Law 25 layers on its own requirements; Ontario health information custodians answer to PHIPA, which is why clinics often ask for charting servers to be in scope.

Authorization

Scanning a system without its owner’s permission can create legal problems, which is why every engagement starts with written authorization. This is a marketing observation, not legal advice.

How a scanning engagement runs

A free review

We start by learning what prompted the question, how many public addresses and websites you have, what sits on the internal network, which cloud services you use, who handles patching today and whether anyone has asked for scan evidence.

A custom proposal and authorization

You receive a custom proposal with the scope, scan types, schedule and report format, with fees quoted in writing, and an authorization document for the system owner to sign before any scanning begins.

Scanning and review

Scans run in the agreed windows. Results are reviewed by a person, false positives removed, findings grouped by fix and ranked by business risk, and the two layer report is delivered and walked through with you.

Every month or on your schedule

For recurring engagements, each cycle brings a new scan, rescans of fixed items, an updated fix tracker and a short comparison with the previous report.

What vulnerability scanning costs

Vulnerability scanning is quoted in writing after the free review. Any scanning software licences held in your organization’s name are shown separately from our fees.

What drives the quote

• How many public IP addresses, websites and web applications are in scope.
• How many internal network ranges, servers and workstations are included.
• Whether internal scans are authenticated, which needs scanning accounts set up and maintained.
• How many cloud accounts and services are reviewed.
• Whether third party permissions must be arranged with hosts or vendors.
• How often scans recur, and whether fix tracking and rescans are included.
• Whether the organization needs scan evidence for card payments, clients or an insurer.

A one time external scan of a small office’s public addresses and website is a far smaller scope than recurring authenticated scans across several sites, their servers and cloud accounts.

Questions to ask a scanning provider

Scan reports are only as good as the judgment applied to them, so ask how a provider turns raw output into decisions.

• Who owns the accounts? The answer should be you, including any scanning licences, the scanning accounts created in your systems and every report.
• Will you obtain written authorization before scanning, and how do you handle hosted and vendor systems?
• Will internal scans be authenticated?
• Does a person review results and remove false positives before I see them?
• How do you rank findings, and will the report group them by fix?
• Will fixes be rescanned to confirm they worked?
• Can I get a short evidence summary for clients or my card processor?

Signs of a weak answer

Be cautious when a provider sends an unreviewed export of hundreds of findings, measures progress only by finding counts, skips authorization, or calls a scan a penetration test.

Your next step

Gather three things before we talk: the web addresses you run, including old campaign or test sites; the cloud services staff sign into; and any questionnaire or letter from a client, insurer or card processor asking about scans. Canada Create will turn that into a proposed scope and schedule in a free vulnerability scanning review, followed by a custom proposal, fees quoted in writing and an authorization form for the system owner to sign.

Call (416) 273-9030, Monday to Friday, 9 am to 6 pm, and Saturday, 10 am to 2 pm. After hours, our 24/7 AI agent answers the toll-free line, +1 (800) 808-9235, and we’ll follow up the next business morning.

Or ask about a vulnerability scan in writing. We reply within one business day.

Find us at 126 Willowdale Avenue, Suite 3, Toronto, scanning authorized systems across Canada.