This chapter covers how to formulate effective remediation recommendations for vulnerabilities discovered during a penetration test. For the PT0-002 exam, this falls under Domain 4 (Reporting and Communication), Objective 4.2: 'Given a scenario, recommend remediation strategies.' Approximately 10% of exam questions touch on this area. You will be expected to prioritize vulnerabilities, propose specific technical fixes, and communicate them clearly to technical and non-technical stakeholders. Mastery of this chapter ensures you can write recommendations that are actionable, risk-based, and aligned with organizational constraints.
Jump to a section
A penetration test is like a full-body medical scan. The pentest report is the diagnosis — it lists every broken bone, infection, and tumor. But a diagnosis alone doesn't heal the patient. The doctor must write a prescription: a specific, actionable plan to fix each problem. For a broken leg, the prescription says 'immobilize with a cast for 6 weeks, then physical therapy.' For a bacterial infection, it says 'take amoxicillin 500mg three times daily for 10 days.' The prescription includes dosage, duration, and follow-up. Without it, the patient knows they are sick but not how to get better. In cybersecurity, the remediation recommendation is that prescription. It tells the system administrator exactly which configuration to change, which patch to apply, which firewall rule to add, and in what order. It also prioritizes: treat the heart attack before the sprained ankle. A good remediation recommendation is precise, measurable, and verifiable — just like a medical prescription. The exam tests whether you can write that prescription, not just identify the disease.
What Are Remediation Recommendations?
Remediation recommendations are the actionable steps provided to an organization to fix the vulnerabilities identified during a penetration test. They form the core of the 'Remediation' section in a pentest report. The PT0-002 exam expects you to understand not only what to recommend, but how to prioritize, communicate, and validate those recommendations.
Why Remediation Matters for the Exam
The exam tests your ability to analyze a scenario and produce a prioritized list of fixes. You must consider:
Risk severity (CVSS score, business impact)
Ease of implementation
Cost and resource constraints
Operational impact (downtime, compatibility)
Regulatory requirements (PCI DSS, HIPAA, GDPR)
Key Components of a Remediation Recommendation
Each recommendation should include: - Vulnerability ID (e.g., CVE-2024-1234 or internal reference) - Affected systems (IP addresses, hostnames, application names) - Risk rating (Critical, High, Medium, Low) based on CVSS v3.1 - Description of the vulnerability and its potential impact - Remediation steps – specific, ordered instructions - Verification method – how to confirm the fix is applied - Priority – order of implementation (e.g., P1, P2, P3) - References – links to vendor bulletins, CVE details, or best practices
Prioritization Frameworks
The exam emphasizes risk-based prioritization. Common frameworks include: - CVSS v3.1 Base Score: 9.0-10.0 Critical, 7.0-8.9 High, 4.0-6.9 Medium, 0.1-3.9 Low - DREAD: Damage potential, Reproducibility, Exploitability, Affected users, Discoverability - OWASP Risk Rating Methodology: Likelihood x Impact - Business Context: Criticality of the asset, data sensitivity, exposure to internet
Common Remediation Categories
#### 1. Patch Management - Apply vendor security patches - Use automated patch management tools (WSUS, SCCM, Ansible) - Test patches in a staging environment before production
#### 2. Configuration Hardening - Disable unnecessary services and ports - Enforce least privilege (e.g., remove admin rights) - Implement secure defaults (e.g., disable default accounts) - Use Group Policy Objects (GPO) for Windows hardening
#### 3. Access Control Changes - Implement multi-factor authentication (MFA) - Revoke unnecessary user accounts - Apply role-based access control (RBAC) - Restrict network access via firewall rules
#### 4. Network Segmentation - Place critical assets in separate VLANs - Use DMZ for public-facing services - Implement micro-segmentation with zero-trust principles
#### 5. Application Security Fixes - Input validation and output encoding - Parameterized queries to prevent SQL injection - Implement Content Security Policy (CSP) headers - Use prepared statements and stored procedures
#### 6. Cryptographic Improvements - Upgrade to TLS 1.2 or 1.3 - Disable weak ciphers (RC4, DES, 3DES) - Use strong key exchange (ECDHE) - Implement HSTS and certificate pinning
Writing Effective Recommendations
Use the SMART criteria: - Specific: 'Change the default password on the admin account' not 'Improve password security' - Measurable: 'Ensure all systems have CVSS score below 7.0' not 'Reduce vulnerabilities' - Achievable: Recommend fixes within the organization's capability - Relevant: Align with business objectives and risk appetite - Time-bound: Provide a timeline (e.g., 'Apply critical patches within 48 hours')
Verification and Validation
After remediation, the pentester (or internal team) should verify the fix:
Re-run the same exploit or scan
Use tools like Nessus, OpenVAS, or custom scripts
Confirm that the vulnerability no longer exists
Document the verification results
Common Remediation Pitfalls
Overly vague recommendations: 'Update software' without specifying version or method
Ignoring dependencies: Patching one system may break another
Not considering rollback: Always have a backout plan
Assuming all vulnerabilities can be fixed: Some may require risk acceptance
Interaction with Other Processes
Remediation is part of the vulnerability management lifecycle: 1. Identification (scanning/pentest) 2. Analysis (risk assessment) 3. Remediation (fixing) 4. Verification (re-scanning) 5. Reporting (tracking metrics)
Exam-Specific Details
The PT0-002 exam expects you to:
Differentiate between remediation, mitigation, and risk acceptance
Know when to recommend a workaround vs. a permanent fix
Understand that not all vulnerabilities can be patched (e.g., legacy systems)
Be able to prioritize based on exploitability and business impact
Configuration Examples
#### Windows: Disable SMBv1 via PowerShell
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force#### Linux: Disable root SSH login
sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl restart sshd#### Network: Block inbound RDP on firewall
access-list 100 deny tcp any any eq 3389
access-list 100 permit ip any anySummary
Remediation recommendations are the bridge between finding vulnerabilities and fixing them. They must be clear, prioritized, and actionable. The exam tests your ability to produce these recommendations in a scenario-based format. Focus on specificity, risk context, and feasibility.
Identify and Classify Vulnerabilities
Start by listing all vulnerabilities found during the penetration test. For each, record the CVE identifier (if available), CVSS v3.1 base score, affected systems, and a brief description. Classify them by severity: Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9). Also note the attack vector (network, adjacent, local, physical) and complexity. This step ensures you have a complete inventory before prioritizing.
Assess Business Context and Risk
Evaluate each vulnerability in the context of the organization's operations. Determine if the affected system hosts sensitive data (PII, PHI, financial), is internet-facing, or supports critical business functions. Consider the likelihood of exploitation and potential impact (data breach, downtime, regulatory fines). This step refines the raw CVSS score into a business risk rating. For example, a medium-severity SQL injection on a public-facing e-commerce site may be treated as critical due to data exposure.
Define Remediation Actions
For each vulnerability, write a specific, actionable remediation step. Avoid vague language like 'apply patches' – instead specify 'upgrade Apache from version 2.4.41 to 2.4.51' or 'change the admin password to a complex 15-character string and enable MFA.' Include configuration changes, patch versions, and any necessary commands. Also note any prerequisites (e.g., 'backup the database before applying the patch').
Prioritize Recommendations
Order the recommendations by priority. Use a combination of severity, business impact, and ease of implementation. Typically, critical vulnerabilities that are internet-facing and have known exploits should be fixed within 24-48 hours. High severity may be 1-2 weeks, medium 1-3 months, and low within the next patch cycle. Create a timeline with milestones. The exam expects you to justify your priority order based on risk.
Document and Communicate
Write the recommendations in a clear, structured format suitable for both technical and non-technical stakeholders. Include an executive summary for management (business risk, cost, timeline) and a technical appendix for system administrators (exact commands, configuration snippets, verification steps). Use tables to show priority, severity, system, and recommended action. Finally, present the findings in a meeting or written report, ensuring all parties understand their responsibilities.
Enterprise Scenario 1: Patch Management in a Large Financial Institution
A penetration test on a bank's online banking platform reveals a critical remote code execution vulnerability in the web server (CVE-2023-44487, HTTP/2 Rapid Reset). The affected system is internet-facing and processes transactions. The remediation recommendation must be precise: 'Upgrade the Apache HTTP Server from version 2.4.55 to 2.4.57 on all production web servers within 48 hours. Apply the patch during a maintenance window to minimize downtime. Verify by running a vulnerability scan against the patched servers.' In production, the bank uses a change management process requiring approval from the security team. The recommendation must include a rollback plan: 'If the patch causes compatibility issues, revert to the previous version and apply a virtual patch via the WAF as a temporary mitigation.' Performance considerations: patching 50 load-balanced servers can be automated using Ansible, but must be staggered to avoid full outage.
Enterprise Scenario 2: Configuration Hardening in Healthcare
A penetration test at a hospital finds that many workstations have local admin rights enabled, allowing privilege escalation. The recommendation is: 'Remove local admin rights from all standard user accounts on Windows 10 workstations. Implement LAPS (Local Administrator Password Solution) to manage local admin passwords. Enforce via GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Deny log on locally for standard users.' In production, this affects 2,000 workstations. The IT team must first identify which users legitimately need admin rights (e.g., for software installation) and create a separate admin account for them. Common misconfiguration: forgetting to test the GPO on a pilot group first, which can lock out users. The recommendation should include a testing phase and a helpdesk plan for users who lose access.
Scenario 3: Network Segmentation in a Retail Chain
A pentest reveals that the point-of-sale (POS) network is on the same flat VLAN as the corporate network, allowing lateral movement from a compromised workstation to the payment card environment. The recommendation: 'Segment the POS network into a separate VLAN (VLAN 50) with strict firewall rules. Only allow communication from POS terminals to the payment gateway on port 443. Block all other inbound traffic from the corporate network. Implement 802.1X on switch ports for device authentication.' In production, this requires re-cabling or reconfiguring switches, which can cause downtime. A phased approach is recommended: first create the VLAN and test with a few terminals, then migrate all terminals during off-hours. Common pitfall: forgetting to update DHCP scopes and DNS records, causing POS terminals to lose connectivity.
What PT0-002 Tests on Remediation Recommendations
The exam objective 4.2 requires you to 'recommend remediation strategies' given a scenario. Questions typically present a vulnerability and ask you to select the best remediation from multiple choices. They also test your ability to prioritize among several vulnerabilities. Key sub-objectives include:
Understanding the difference between remediation (fixing the root cause), mitigation (reducing risk without fixing), and risk acceptance (acknowledging the risk)
Knowing when to recommend a workaround vs. a permanent patch
Applying CVSS scoring to prioritize
Considering business impact and operational constraints
Common Wrong Answers and Why Candidates Choose Them
Choosing 'Apply all patches immediately' without considering downtime: Candidates think patching is always the answer, but the exam may present a scenario where patching would cause critical system downtime. The correct answer might be to implement a virtual patch or WAF rule as a temporary mitigation.
Selecting the highest CVSS score vulnerability as top priority without business context: The exam loves to test that a critical vulnerability on an isolated internal server may be lower priority than a high-severity vulnerability on an internet-facing server containing PII.
Recommending a full system rebuild when a simple config change suffices: Over-engineering is a trap. For example, for a weak password, recommending a password change is more appropriate than rebuilding the server.
Ignoring regulatory requirements: A vulnerability that causes PCI DSS non-compliance must be prioritized even if its CVSS score is medium.
Specific Numbers and Terms Appearing on the Exam
CVSS v3.1 severity bands: Critical 9.0-10.0, High 7.0-8.9, Medium 4.0-6.9, Low 0.1-3.9
Common remediation types: patch, configuration change, access control, network segmentation, decommissioning
Verification methods: re-scan, manual test, log review
Terms: 'risk acceptance', 'risk mitigation', 'risk transfer', 'compensating control', 'workaround', 'permanent fix'
Edge Cases and Exceptions
Legacy systems that cannot be patched: recommend compensating controls like network isolation, strict firewall rules, or decommissioning if possible.
Third-party software with no vendor patch: recommend removing the software or using a different product.
Vulnerabilities that require multiple steps to remediate: recommend a phased approach with milestones.
When a vulnerability is not exploitable due to existing controls: recommend risk acceptance if the cost of fixing outweighs the risk.
How to Eliminate Wrong Answers
If an option says 'ignore the vulnerability' – it's almost always wrong unless it's a risk acceptance decision documented in writing.
If an option recommends a complex solution for a simple problem – look for a simpler one.
If an option doesn't address the root cause – e.g., 'add a firewall rule' for a SQL injection vulnerability when the fix should be input validation.
If an option would cause significant operational impact without justification – the exam expects you to consider business continuity.
Remediation fixes the root cause; mitigation reduces risk without fixing.
Prioritize using CVSS score combined with business context (data sensitivity, exposure, criticality).
Use SMART criteria: Specific, Measurable, Achievable, Relevant, Time-bound.
Include verification steps in every recommendation.
For legacy systems that cannot be patched, recommend compensating controls like network isolation.
Document risk acceptance formally when remediation is not feasible.
Communicate remediation in both executive summary and technical appendix.
These come up on the exam all the time. Here's how to tell them apart.
Remediation
Fixes the root cause of the vulnerability
Example: installing a security patch
Permanently eliminates the vulnerability
Often requires a maintenance window
Verification: re-scan shows vulnerability gone
Mitigation
Reduces risk without removing the vulnerability
Example: adding a firewall rule to block exploit traffic
Temporary or compensating control
Can be implemented with minimal downtime
Verification: exploit attempt is blocked, but underlying issue remains
Mistake
All vulnerabilities must be patched immediately.
Correct
Patches can cause downtime or break functionality. The exam expects you to consider business impact and sometimes recommend temporary mitigations (e.g., WAF rules) until a maintenance window.
Mistake
CVSS score alone determines priority.
Correct
CVSS is a starting point, but business context (data sensitivity, internet exposure, criticality) often overrides raw score. A medium vulnerability on a public-facing server may be higher priority than a critical one on an isolated internal system.
Mistake
Remediation and mitigation are the same thing.
Correct
Remediation fixes the root cause (e.g., applying a patch). Mitigation reduces the risk but does not eliminate the vulnerability (e.g., adding a firewall rule to block exploit traffic). The exam distinguishes between them.
Mistake
If a vulnerability cannot be patched, the only option is risk acceptance.
Correct
There are compensating controls: network segmentation, strict access controls, monitoring, or decommissioning the system. Risk acceptance is only appropriate after exhausting other options and with formal sign-off.
Mistake
The remediation recommendation should be written in technical jargon only.
Correct
The report must be understandable to both technical and non-technical audiences. Use an executive summary for management and detailed technical steps for administrators.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Remediation completely eliminates the vulnerability, usually by patching or reconfiguring. Mitigation reduces the risk but does not remove the vulnerability, often through compensating controls like firewall rules or monitoring. The exam expects you to recommend remediation when possible, but mitigation when a full fix is not immediately feasible.
Start with the CVSS base score, then adjust for business context: internet-facing systems, data sensitivity, exploitability, and regulatory requirements. Critical vulnerabilities with known exploits and high business impact should be fixed within 24-48 hours. Lower severity issues can be scheduled in regular patch cycles.
First, look for compensating controls: network segmentation, strict access controls, WAF rules, or monitoring. If none are feasible, recommend decommissioning the system. If that's not possible, formally document risk acceptance with sign-off from management. The exam expects you to explore all options before accepting risk.
Very detailed. Include exact commands, configuration changes, patch versions, and verification steps. For example, instead of 'update software', specify 'upgrade Apache from 2.4.41 to 2.4.51 using the vendor's official package manager'. This ensures the system administrator can act without ambiguity.
A compensating control is an alternative security measure that reduces the risk of a vulnerability when the primary fix cannot be applied. Examples include network isolation, enhanced logging, intrusion prevention systems, or manual workarounds. The exam may ask you to recommend a compensating control when patching is not possible.
Yes. Provide a realistic timeline based on severity and operational constraints. For example, critical vulnerabilities may require remediation within 48 hours, high within 2 weeks, medium within 1 month, and low within the next patch cycle. The timeline should be agreed upon with the client.
Risk acceptance is a formal decision to acknowledge a vulnerability and not fix it, usually because the cost of remediation outweighs the risk, or the system is being decommissioned soon. It must be documented with sign-off from an authorized stakeholder. The exam expects you to recommend risk acceptance only after exploring all other options.
You've just covered Remediation Recommendations — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?