If you never check your house for unlocked windows, you will only find out when a burglar walks through them. In IT, waiting for a real cyber attack to reveal your network’s weak spots is disastrous — and that is why vulnerability management and penetration testing exist. For the 350-701 exam, you need to understand the difference between finding problems and simulating attacks, and know how both fit into a security professional’s daily work.
Jump to a section
A simple way to picture Vulnerability Management and Penetration Testing
Your house, on a quiet suburban street. You have a front door lock, a few window latches, and maybe a motion-sensor light in the back garden, but you have never actually checked if any of them work properly.
One day, a friend who installs security systems offers to do a ‘vulnerability audit.’ They walk around your property, checking every door, window, and even the flimsy garden shed hasp. They find that your back-door lock is loose, one window latch doesn’t catch properly, and a side gate has no lock at all. They hand you a list of these issues, ranked by how serious they are — the window latch is a minor risk (a thief would have to work hard), but the open side gate is critical (someone could walk right in). That is vulnerability management: systematically finding, classifying, and fixing weaknesses before a real intruder shows up.
Then your friend offers a ‘penetration test.’ This time they dress up in dark clothes, borrow a set of lock picks, and actually try to break in. They don’t just list weaknesses — they actively exploit them. They manage to pop the back-door lock in under a minute and walk into your kitchen. That is penetration testing: simulating a real attacker’s actions to prove that the weaknesses actually matter. The first tells you what is wrong; the second proves it can be exploited.
Let us start with the fundamental problem: every piece of software, every router, every server, and every cloud service has flaws. These flaws are called vulnerabilities. A vulnerability is a weakness that a cyber attacker could potentially use to break into a system, steal data, or disrupt operations. Vulnerabilities exist because software is written by humans, and humans make mistakes — a programmer might forget to check user input properly, a configuration file might have a default password left unchanged, or a design decision might allow data to leak across trust boundaries.
The goal of a security team is to find and fix those vulnerabilities before an attacker does. This is where vulnerability management and penetration testing come in. They are two distinct but complementary activities.
Vulnerability Management is a continuous, organised process. It is not a one-time scan. It involves running automated tools that scan your network, systems, and applications, comparing them against known databases of security issues (like the National Vulnerability Database — a massive catalogue of known software flaws). These tools produce a list of potential vulnerabilities, often numbering in the thousands in a medium-sized organisation. A human analyst then triages the list: they assess each finding to decide how serious it is based on the severity score (Common Vulnerability Scoring System, or CVSS), whether the vulnerability is actually reachable from the internet, and whether a fix (called a patch) is available. The analyst then prioritises the most dangerous vulnerabilities and assigns them to the teams that will apply patches or change configurations. This cycle happens on a schedule — weekly, monthly, or quarterly — to keep up with new vulnerabilities published every day.
Penetration Testing (often called a ‘pentest’) is a focused, manual exercise. A penetration tester — a security professional with deep technical skills — tries to actively exploit vulnerabilities to prove they can be used to achieve a specific goal, such as gaining access to a sensitive database or taking control of a server. Unlike vulnerability scanning, a pentest is not limited to known vulnerabilities. The tester may also try to find new, unknown vulnerabilities, chain together multiple small issues to bypass security controls, or use social engineering (tricking employees to give up passwords). A pentest is typically performed once or twice a year, or after major system changes. The output is a detailed report that includes proof of what was exploited and recommendations for fixing each issue.
Why do you need both? Vulnerability management gives you broad coverage — it tells you where most of your weaknesses are. But automated scanners can miss subtle issues or produce false positives (reporting a vulnerability that does not actually exist in your specific setup). Penetration testing provides depth — it proves whether those weaknesses can actually be used against you. A classic analogy is that vulnerability management is like having an annual health check-up that tests your blood pressure and cholesterol, while a penetration test is like a stress test on a treadmill — it shows what happens when you actually push the system under attack conditions.
The 350-701 exam specifically asks you to describe these concepts and contrast them. You need to know that vulnerability management is ongoing and broad, while penetration testing is periodic and deep. You also need to understand terms like ‘false positive’, ‘false negative’, ‘CVSS score’, and ‘exploit’. The exam often includes scenario-based questions where you have to decide whether a situation calls for a vulnerability scan or a penetration test.
Finally, note the difference between ‘vulnerability assessment’ and ‘penetration test’. A vulnerability assessment is exactly what it sounds like — it assesses and lists vulnerabilities. A penetration test goes further; it actively attempts to exploit. In the exam, do not confuse the two. A vulnerability assessment stops at the list; a penetration test takes the next step and tries to break in.
Planning and scoping
Before any scanning or testing begins, the security team defines the scope: which systems, networks, or applications are in scope? What is out of bounds? They also set rules of engagement — for example, no denial-of-service attacks during business hours. Written authorisation is obtained from management to ensure legality.
Reconnaissance
The tester gathers information about the target using passive techniques (searching public databases, looking up DNS records) and active techniques such as pinging IP addresses or enumerating open ports. This phase identifies potential entry points without actually attacking.
Vulnerability discovery
Automated tools scan the target systems for known vulnerabilities. The scanner compares software versions and configurations against a database of known issues. This produces a list of potential vulnerabilities, often categorised by severity.
Exploitation
The tester attempts to exploit the discovered vulnerabilities. This involves running exploit code, manipulating inputs (e.g., SQL injection), or using stolen credentials to gain access. The goal is to demonstrate that a vulnerability can be used to compromise a system.
Post-exploitation and reporting
After gaining access, the tester documents what they have accessed (e.g., sensitive files, databases) and assesses the extent of potential damage. They then write a report detailing each vulnerability, how it was exploited, the risk level, and recommended remediation steps.
Imagine a medium-sized financial services company called ‘SecurePay Ltd.’ They process online payments for small businesses. Their IT environment includes web servers, application servers, a customer database, and a cloud-based payment gateway. Their security team consists of three people, including a manager named Priya.
Priya knows that her company is a target for attackers because they handle credit card data. So she establishes a vulnerability management programme. Every Tuesday night, an automated scanner runs against all of SecurePay’s internal servers and network devices. The scanner uses a database of known vulnerabilities — thousands of them for operating systems like Windows Server and Linux, for web servers like Apache and Nginx, and for database software like MySQL.
On Wednesday morning, Priya reviews the scan results. She sees 150 new findings from last night’s scan. She categorises them by severity:
Critical (CVSS 9.0-10.0): a known exploit exists for a web server vulnerability, and the server is exposed to the internet.
High (CVSS 7.0-8.9): a vulnerability in the database software, but it requires local access to exploit.
Medium (CVSS 4.0-6.9): a missing patch on an internal development server that no one uses for sensitive data.
Low (CVSS 0.1-3.9): minor configuration issues that do not pose an immediate risk.
She assigns the critical finding to the web team with a deadline of 72 hours to apply the patch. The high finding goes to the database team for the next maintenance window. She archives the low findings to be reviewed during the quarterly review.
This process repeats every week. But Priya also knows that automated scanners miss things. So twice a year, she hires an external penetration testing company. They spend two weeks actively trying to break into SecurePay’s systems. The testers use the same techniques as real attackers: they scan for software versions, search for default credentials, try SQL injection (inserting database commands into web forms), and attempt to trick employees with phishing emails.
The penetration testers find a vulnerability the scanner never spotted: a misconfigured firewall rule allows traffic from an old partner network that should have been blocked years ago. Using that opening, they bypass the perimeter firewall and reach a server that houses customer email addresses. They prove they can extract 10,000 records without triggering any alarms. Priya’s team is shocked. They immediately update the firewall rules and add monitoring for that network path.
What does Priya do with the results? She documents everything in a report for management. She uses the penetration test findings to justify a budget increase for additional security tools. She also updates the vulnerability management system to add a check for that specific firewall misconfiguration. The combination of automated weekly scans and deep manual tests every six months gives SecurePay a defence that is both broad and deep.
The key lesson: vulnerability management keeps you aware of known problems at scale. Penetration testing catches the clever, subtle issues that scanners cannot see. Both are essential for a mature security programme.
The 350-701 exam tests your understanding of vulnerability management and penetration testing in two main ways: conceptual definitions and scenario-based decision making. Expect around 3-5 questions on this topic, primarily from Domain 1 (Security Concepts) and Domain 3 (Security Operations).
First, the exam loves to check that you can distinguish between vulnerability assessment, vulnerability management, and penetration testing. The classic trap: a question describes a monthly automated scan that produces a list of vulnerabilities and asks what process this is. The correct answer is ‘vulnerability assessment’ — not ‘vulnerability management’ (which includes the full lifecycle of prioritising and remediating) and not ‘penetration testing’ (which is active exploitation). The exam writers deliberately craft scenarios where a single vulnerability assessment is described, but the answer choices include ‘vulnerability management’ to tempt you. Memorise the distinction: assessment = snapshot; management = ongoing process.
Second, know the phases of a penetration test. The standard framework used in the exam is:
Planning and scoping: defining what systems are in scope, what rules of engagement apply (e.g., no denial-of-service attacks), and getting written authorisation.
Reconnaissance: gathering information about the target (public IP addresses, employee names, etc.).
Vulnerability discovery: scanning and probing for weaknesses.
Exploitation: actively trying to break in.
Post-exploitation: what access can be gained after initial compromise.
Reporting: documenting findings and recommendations.
Be prepared for a question that asks, “Which phase involves gaining initial access to a target system?” The answer is ‘exploitation’, not ‘reconnaissance’ — a common mistake.
Third, the exam tests your understanding of Common Vulnerability Scoring System (CVSS). The key facts: CVSS scores range from 0.0 to 10.0, with 10.0 being most severe. The score is composed of three metric groups: Base (how bad the vulnerability is inherently), Temporal (how the risk changes over time, e.g., if an exploit becomes publicly available), and Environmental (how the vulnerability affects your specific organisation). For the exam, you mainly need to know that the Base score is the standard one used for prioritisation, and that CVSS 9.0-10.0 is Critical, 7.0-8.9 is High, 4.0-6.9 is Medium, and 0.1-3.9 is Low. A typical question: “A vulnerability has a CVSSv3 Base Score of 9.8. What severity rating does this correspond to?” Answer: Critical.
Fourth, exam questions often ask about false positives and false negatives. Know the definitions:
False positive: the scanner reported a vulnerability that does not actually exist (e.g., it thinks a server is running an old version of Apache, but the version was actually patched in-place).
False negative: the scanner missed a vulnerability that does exist (e.g., it did not detect a web application vulnerability because it only checked surface-level inputs).
A question might say: “Your vulnerability scan reports 50 critical vulnerabilities. Manual verification shows that 10 are not actually present. What term describes these 10 findings?” Answer: false positives.
Fifth, be clear on the difference between authenticated versus unauthenticated scans. Unauthenticated scans show what an outsider can see (e.g., from the internet). Authenticated scans log into the system with valid credentials and show more detailed vulnerabilities (e.g., local privilege escalation paths). The exam may ask: “Which type of scan reduces false positives by accessing the system’s internal configuration?” Answer: authenticated scan.
Finally, a frequent exam trap: the question describes an ‘ethical hacker’ performing a simulated attack, and the answer choices include ‘red team’, ‘blue team’, and ‘penetration tester’. The correct term for a professional who simulates attacks to test defences is ‘penetration tester’ or ‘ethical hacker’. ‘Red team’ is a broader term for a team that simulates adversaries, often involving social engineering and multiple attack vectors, not just technical exploitation. In the exam, ‘red team’ is usually a distractor when the scenario describes only a technical penetration test.
Vulnerability management is a continuous process of scanning, prioritising, and patching vulnerabilities across the entire environment.
Penetration testing is a simulated attack by human experts to prove that vulnerabilities can actually be exploited.
A vulnerability assessment stops at identifying and listing vulnerabilities; a penetration test goes further by attempting to exploit them.
The Common Vulnerability Scoring System (CVSS) provides a standardised severity score from 0.0 to 10.0 to help prioritise remediation efforts.
False positives are scan results that incorrectly report a vulnerability; false negatives are vulnerabilities that the scan fails to detect.
Authenticated scans with valid credentials provide deeper visibility and reduce false positives compared to unauthenticated scans.
These come up on the exam all the time. Here's how to tell them apart.
Vulnerability Management
Continuous, ongoing process repeated on a schedule (weekly/monthly)
Primarily automated scanning using signature databases
Produces a list of potential vulnerabilities with severity scores
Penetration Testing
Periodic, project-based (annually or after major changes)
Manual, human-driven with expert judgment
Produces a detailed report with proof of exploit demonstration
Vulnerability Assessment
Only identifies and lists vulnerabilities
Does not attempt to exploit any vulnerability
Broad coverage but shallow depth
Penetration Test
Actively tries to exploit vulnerabilities to prove impact
Seeks deep access and chains multiple issues
Narrower scope but much deeper analysis
False Positive
Scanner reports a vulnerability that does not exist
Wastes time and resources in investigation
Example: scanner says a server is vulnerable, but it is actually patched
False Negative
Scanner fails to detect a real vulnerability
Leaves a dangerous weakness unknown
Example: scanner does not detect SQL injection in a web form
Mistake
Vulnerability management and penetration testing are the same thing, just called different names.
Correct
They are complementary but distinct. Vulnerability management is an ongoing process of scanning and remediation. Penetration testing is a one-off or periodic manual effort to actively exploit vulnerabilities.
Both involve finding weaknesses, so beginners assume they are interchangeable. But the methodology, frequency, and depth differ significantly.
Mistake
A vulnerability scanner can find every vulnerability in a network.
Correct
No scanner is perfect. Scanners can only find known vulnerabilities that match their signature database. They miss logic flaws, chained attacks, and zero-day vulnerabilities. Penetration testers often find issues scanners miss.
Vulnerability scanners are marketed as comprehensive, so beginners overestimate their capability. Real-world security requires both automated and manual methods.
Mistake
Penetration testing is only necessary once, after initial setup.
Correct
Penetration testing should be performed regularly — at least annually — and after any major change (such as a new application, network redesign, or cloud migration).
Beginners think of security as a one-time project. In reality, threats evolve, systems change, and new vulnerabilities emerge constantly.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A vulnerability assessment is an automated scan that identifies potential vulnerabilities. A penetration test is a manual, active attempt to exploit those vulnerabilities to prove they are real threats. The assessment lists issues; the pentest proves they can be used to break in.
Yes. Vulnerability management gives you broad, continuous coverage. Penetration testing catches deep, subtle issues that automated scanners miss. Relying on only one leaves you exposed.
CVSS (Common Vulnerability Scoring System) is a standardised scoring system from 0.0 to 10.0 that rates the severity of a vulnerability. Scores 9.0-10.0 are Critical, 7.0-8.9 are High, 4.0-6.9 are Medium, and 0.1-3.9 are Low. Higher scores mean higher risk.
A false positive is when the scanner reports a vulnerability that does not actually exist in your environment. For example, it might detect an out-of-date software version, but you have patched it manually. You need to verify findings manually to avoid wasting time on non-issues.
At least annually, and after any major change such as a new application deployment, network redesign, or migration to the cloud. Regulations like PCI DSS also mandate specific testing frequencies.
Unauthenticated scanning simulates an outsider with no access, scanning from the network perimeter. Authenticated scanning uses valid credentials to log into systems, giving deeper visibility into internal configurations and reducing false positives.
You've finished Vulnerability Management and Penetration Testing. Continue through the 350-701 study guide to build a complete picture of the exam.
Done with this chapter?