Mission 27

Vulnerability Management and Security Testing

Turn scattered update alerts and scan reports into a calm, repeatable cycle: know what you have, confirm what is weak, fix what matters most first, and prove the fix worked. Learn why every security test needs written permission and a clear scope.

15 minutesHUMANWALL ChampionJump to scenario & quiz ↓

In this mission you will

Describe the vulnerability management cycle: inventory, identify, validate, prioritise, assign, remediate and verify.
Prioritise findings using exposure, exploitability, business impact and existing safeguards, not severity labels alone.
Explain why security testing is only acceptable with written authorisation, an agreed scope and rules of engagement.
Set up a simple vulnerability register that records an owner, a due date and verification status for each finding.

What a vulnerability really is

A vulnerability is a weakness that someone could use to harm your business. It might be an unpatched router, an old plugin on the company website, a shared admin account, a cloud folder open to "anyone with the link", or a laptop that has not received updates for months. Vulnerabilities are normal. Every business has some, because software changes constantly and people are busy. The goal is not to have zero weaknesses; it is to find them in a planned way, fix the important ones quickly and know what is still open.

The vulnerability management cycle

1Inventory: list the assets you need to protect, such as laptops, phones, servers, the website, the billing software, cloud accounts, routers and printers. You cannot fix what you do not know exists.
2Identify: collect weaknesses from vendor update notices, security advisories, approved scanning tools, your IT provider's reports and authorised tests.
3Validate: confirm that each finding is real and applies to your version and setup. Scanners sometimes report problems that do not exist, and sometimes miss real ones.
4Prioritise: decide what to fix first based on exposure, exploitability, business impact and the safeguards already in place.
5Assign: give every finding one named owner and a realistic due date. "IT will look at it" is not an owner.
6Remediate: apply the update, change the setting or retire the system, using normal change control so you do not break something the business depends on.
7Verify: check that the fix actually worked, then record the evidence and close the item.

Prioritise with business context, not labels alone

Severity ratings from vendors and scanners are a useful starting point, but they do not know your business. Ask four questions for each finding. Exposure: can it be reached from the internet, or only from inside the office network? Exploitability: is there public information that attackers are already using this weakness? Impact: what would happen to the business if this asset were misused, for example billing stopping or customer data leaking? Safeguards: is something else already reducing the risk, such as MFA, network separation or the device being switched off? A "medium" weakness on your internet-facing customer portal may deserve attention before a "critical" one on an isolated test laptop kept in a cupboard.

What a simple vulnerability register should record

Asset name and what it is used for.
Short description of the finding and where it came from (advisory, scan, IT provider, test).
Severity, exposure and business impact in plain words.
Owner and due date.
Action taken, or the reason it is accepted for now and who approved that decision.
Verification status and date: how you confirmed the fix worked.

Types of security testing in plain terms

A vulnerability scan uses an approved tool to look for known weaknesses and missing updates. A configuration review compares your settings against a good-practice checklist. A penetration test is a deeper, authorised exercise in which a qualified tester tries to show how weaknesses could be combined, within strict limits. For most small businesses, the best value comes from keeping an accurate inventory, applying updates on time and running approved scans regularly. Commission a penetration test when you have critical internet-facing systems or a customer asks for one, and always agree the scope in writing first. A clean report on one day is a snapshot, not a guarantee.

Practical business example

Shree Ganesh Packaging finds its forgotten server

Shree Ganesh Packaging, a fictional 40-person carton maker in Rajkot, asked its IT partner for an approved scan of its office network and website. The report listed 63 findings, which felt overwhelming. Owner Meena Desai and office manager Kunal sat down with the partner for an hour. First they checked the asset list and discovered an old file server nobody remembered, still reachable from the internet for a former remote-access setup. They validated the findings and found several did not apply to their versions. They then ranked the rest: the forgotten server and an outdated website plugin came first because both were internet-facing and held business data. Each item got an owner and a date. The server was taken offline after its files were moved, the plugin was updated, and the partner re-ran the scan two weeks later to confirm both were resolved.

The lesson: A long report becomes manageable when you validate it, rank by exposure and impact, give each item an owner and verify the fix. The most important finding was an asset nobody had on the list.

Key takeaways

Start with an accurate asset inventory; forgotten systems are often the riskiest.
Validate findings, then prioritise by exposure, exploitability, impact and safeguards, not labels alone.
Every finding needs one named owner, a due date and a recorded decision.
Never scan or test any system without written authorisation and an agreed scope.
A fix counts only when it has been verified and the evidence recorded.