Key points
- Continuous Threat Exposure Management (CTEM) is Gartner’s five-stage framework for continuously reducing cyber exposure.
- A 90-day, wave-based remediation plan operationalizes CTEM’s mobilization stage, fast-tracking actively exploited findings instead of waiting for the standard 90-day checkpoints.
- Effective vulnerability prioritization now combines CVSS v4.0, EPSS, and CISA KEV status since severity alone doesn’t indicate real-world urgency.
- The EU AI Act, effective August 2, 2026, requires AI-integrated applications and agents to have their own remediation track for prompt injection and model manipulation findings.
- Remediation evidence should map directly to the relevant framework so auditors can trace findings to proof without further explanation.
Penetration testing (pen testing) simulates a cyberattack to identify system vulnerabilities, exposing potential attack vectors before actual incidents occur. But these days, finding vulnerabilities is easy. What’s more challenging is keeping up with the pace at which attackers are exploiting whatever they find.
Recent industry research reveals that the median weaponization window for a majority of newly discovered vulnerabilities is 48 hours. To make matters worse, more and more attackers are using AI to automate reconnaissance and exploit chaining at machine speed.
This means that having a remediation workflow built around a single point-in-time report is no longer enough. Security teams need a workflow that continuously scans and manages exposures.
The good news is that Gartner has developed a new security framework that turns reactive vulnerability scanning into a proactive, risk-driven strategy called Continuous Threat Exposure Management (CTEM).
This guide explores what CTEM is, how it works, and how you can incorporate a 90-day remediation strategy into its mobilization stage.
What is Continuous Threat Exposure Management (CTEM)? A quick overview
Gartner defines Continuous Threat Exposure Management (CTEM) as a “programmatic discipline for continuously evaluating an organization’s exposure to cyberthreats to drive prioritized, validated, and business-aligned remediation and risk reduction.”
Simply put, it’s a framework for proactively managing and mitigating threat exposure. Instead of checking for and testing vulnerabilities quarterly, CTEM treats exposure as a moving target that must be continuously tracked, prioritized, and mitigated. It combines vulnerability management, attack surface management, and posture validation into one operating model.
The CTEM cycle is made up of five stages:
- Scoping: Determines the systems, environments, and processes that have the most operational impact if compromised.
- Discovery: Continuously identifies assets and potential exposures across all relevant environments. This typically includes cloud, on-premises infrastructure, SaaS platforms, identity and access systems, endpoints, and applications.
- Prioritization: Ranks risks by exploitability, business impact, and likelihood of attack path. This is where vulnerability management signals, such as CVSS, EPSS, and KEV status, come in.
- Validation: Simulate real attack paths to determine whether the existing controls can actually stop an attacker. Penetration testing is a key validation activity in a CTEM cycle, allowing security teams to confirm which exposures are actually exploitable, identify attack paths to critical assets, and verify that defensive controls are working as intended.
- Mobilization: Remediation efforts are coordinated, tracked, and pushed to closure across security and IT teams.
One of the biggest limitations of traditional pen testing is that it only represents a snapshot in time. It’s useful for identifying exploitable vulnerabilities, but if the environment continues to evolve after the assessment (as it normally does), you’ll miss new exposures.
CTEM addresses this problem by treating pen tests as continuous validation rather than a standalone security exercise. It ensures that the findings from pen tests remain connected to the rest of the cycle.
For instance, the 90-day remediation program that follows can be included in the mobilization phase. Rather than just handing off a report and tracking remediation tickets, you can use the validated findings to drive meaningful risk reduction across the organization.
The goal here isn’t just to close the findings from the latest pen test, but to reduce the exposures that pose the greatest risk to the business. As the remediation program progresses, security and IT teams can go back to the Discovery, Prioritization, and Validation stages to look for emerging risks and continue the CTEM cycle.
Improve service delivery with real-time reports and dynamic scheduling.
Operationalize CTEM-aligned penetration testing remediation in 90 days
In a CTEM-based program, exposures are prioritized according to their exploitability, business impact, and their role in potential attack paths. High-risk exposures receive immediate attention, while medium- to low-risk issues are deferred to a structured 90-day remediation plan.
The 90-day timeframe prevents lower-priority findings from becoming backlogs by creating a sense of urgency around the entire remediation effort. It essentially provides teams with a practical deadline to review, remediate, and mitigate minor findings while the CTEM cycle continues. This ensures that every finding you get from a pen test is resolved, not just left on the back burner.
📌Prerequisites:
- Final pen test report with severity ratings (ideally CVSS v4.0 vectors and not just a single score) and evidence
- Exploit context for each finding: CISA Known Exploited Vulnerabilities (KEV) status, and if possible, Exploit Prediction Scoring System (EPSS) probability
- Asset and data classification to translate technical risk to business impact
- Named owners for remediation, validation, and change approvals
- Ticketing workspace and a shared evidence folder for results
Step #1: Standardize pen test reports and assign ownership
Penetration test results often come in multiple formats, varying severity ratings, inconsistent naming conventions, and sometimes overlapping findings. Standardizing your findings by assigning IDs, mapping them to assets, and categorizing them by CWE or risk creates clean documentation that you can use to base future remediation work on.
Recommended action plan:
- Import all findings: Leverage an ITSM software to centrally store and track pen test results and exposures surfaced by continuous discovery and scanning between the tests.
- Assign a unique ID: Assigning a unique identifier to each surfaced vulnerability streamlines issue tracking from detection to validation.
- Tag items with layered risk context, not just severity: Note the CVSS v4.0 vector, the EPSS probability, and the CISA KEV status of the affected assets. A CVSS 9.8 issue with no real-world exploitation evidence and no internet exposure is very different from a CVSS 7.5 issue that’s being actively exploited on an internet-facing system.
- Assign two roles per finding: Assign an owner to implement and coordinate the fix, and a verifier to confirm and document the resolution workflow.
- Capture change windows and dependencies: This minimizes downtime conflicts and ensures fixes align with maintenance schedules.
Standardizing your findings by assigning IDs, mapping to assets, and categorizing by CWE or risk creates clean documentation that you can base future remediation work on.
Step #2: Build a 3-part, 90-day penetration testing remediation workflow
Pen tests can combine urgent vulnerabilities with low-risk issues, which can overwhelm remediation workflows and lead to missed deadlines or incomplete work. A 90-day wave-based approach can help organize the findings, but it should be sequenced by real-world exploitability and not just technical complexity.
Recommended action plan:
- Day 0 to 7: Triage anything KEV-listed or being actively exploited immediately instead of waiting for wave one. If a finding is in CISA’s KEV catalog or has a high EPSS score, you must treat it as an emergency change regardless of which bucket it would otherwise fall into.
- Days 1 to 30: Address easily exploitable vulnerabilities that can be fixed quickly, such as missing patches, policy misconfigurations, weak credentials, or exposed admin portals.
- Days 31 to 60: Remediate vulnerabilities that require complex code-level adjustments and cross-team coordination between developers, network engineers, and testers. Integrate testing during maintenance windows to manage its impact.
- Days 61 to 90: Close low-risk items, implement configuration hardening, rotate credentials, and finalize your documentation.
- Lock the plan to your team’s calendar: Set start and end dates for each wave, and align these dates with your organization’s release and management change cycles. Treat these dates as agreed commitments across teams and ensure they are visible to all stakeholders.
Step #3: Create a change checklist per penetration test finding
Crafting standardized checklists guides your vulnerability remediation strategy and changes made within live client environments. Here are some steps to consider:
- Define proposed control change. Describe the changes needed to address identified vulnerabilities, such as patches, configuration updates, code fixes, or policy adjustments. Note any services, users, or systems affected.
- Build a test plan. Replicate identified issues as found in pen tests, then define success criteria after a fix is applied.
- Prepare a rollback checklist. Define the steps technicians need to take when a fix unintendedly breaks a system or degrades endpoint performance.
- Attach evidence. Include both pre-and post-fix documentation from pen test results directly to their unique ID to support future validation steps. Capture the task owner, date, and test environment used for verification consistency.
Doing these steps reduces the occurrence of partial fixes, missed dependencies, and the risk of introducing new vulnerabilities to client environments.
Step #4: Prioritize clear risks uncovered by penetration testing stages
Proper vulnerability prioritization enables you to focus on high-risk vulnerabilities, allowing you to immediately close critical attack vectors. Tale these steps for example:
Recommended action plan:
- Define “clear risk” items: Spot and prioritize vulnerabilities with public exploits, KEV-catalog status, high EPSS scores, or straightforward attack methods, such as:
- Weak or missing authentication controls
- Insecure direct object references (IDORs)
- Injection flaws (e.g., SQL, command, or LDAP)
- Exposed administrative interfaces
- Weak access control
- Prompt injection and other AI/LLM-specific flaws
- Apply a minimum viable fix: Use minimal and targeted fixes that close vulnerabilities without causing significant system impact or changes. Avoid large redesigns, as the goal is rapid threat containment, not to overhaul stacks.
- Document and schedule follow-ups: After closing the gaps, identify necessary improvements or redesigns required for long-term resilience. Schedule these as planned tasks in future remediation waves.
This approach minimizes your client’s exposure time, reduces the likelihood of compromise, and demonstrates decisiveness in addressing threats once they surface.
Step #5: Validate every implemented fix and capture evidence
Retesting each fix using the same method found during pen testing ensures that vulnerabilities are closed and won’t resurface. Below is a validation workflow you can build upon:
- Recreate pen test conditions (e.g tools, payloads, or requests).
- Run the same attack simulation or exploit to verify the effectiveness of your fix. Observe system behavior to determine if indicators of compromise or vulnerabilities remain; their absence indicates that the vulnerability is closed.
- Save both before-and-after test evidence, such as console output, screenshots, or network traces, that demonstrate successful vulnerability remediation. Label and attach these artifacts to the finding’s unique ID within your tracker or evidence repository.
- Document who verified the fix, validation date, and the tools used. Capture test notes or observations that can help explain the fix in detail.
Additionally, evidence becomes your defensible record that risks are truly closed and not shifted elsewhere in the system.
Step #6: Capture exceptions in penetration testing remediation workflows
Some vulnerabilities can’t be closed within 90 days. Documenting these lapses as exceptions ensures that deferred items are accounted for. The exception handling steps below offers a key understanding of this workflow:
- Assign an owner, capture the rationale behind the exception, temporary fix, and expiry date.
- Hold a short review meeting or checklist run, preferably weekly, to confirm the following:
- Verify if temporary fixes are still effective.
- Conditions haven’t drifted to make remediation possible.
- Expiry dates are updated or closed appropriately.
- If a vulnerability can’t be remediated permanently, escalate it for a design review to plan system architecture or address business acceptance risk changes.
Keeping unremediated vulnerabilities tracked, owned, and reviewed until a permanent fix is available minimizes blind spots in client environments.
Step #7: Address web application vulnerabilities systematically
Web application vulnerabilities typically follow repeatable patterns; once you’ve seen an issue, you’ll likely find the same issue across multiple routes, modules, or applications. Systematically addressing these types of vulnerability through well-designed changes eliminates related issues in one go.
Recommended action plan:
- Group similar findings: Categorize web-related findings by type, and identify where they occur repeatedly; for example, through shared APIs, templates, or middleware. Include any AI/LLM-integrated endpoints in this grouping, since they’re increasingly a shared component across multiple applications.
- Define the common pattern: Understand the why behind the identified vulnerability. For instance, if multiple endpoints are vulnerable to SQL injection, the real issue may lie in unvalidated query inputs or in missing data-layer sanitization.
- Centralize fix distribution: Apply controls in shared code paths or through centralized components so that the fix deploys automatically across the entire environment.
- Verify effectiveness and capture fixes: Document and retest fixes across affected endpoints or applications to confirm whether they have mitigated the entire class of vulnerabilities.
Step #8: Strengthen your pen testing roadmap by closing gaps
Aside from external exploits, attackers can bypass your defenses by leveraging insider threats, such as overprivileged accounts, exposed credentials, or weak configurations. See the action plan below for utilizing access controls:
- Enforce least privilege access. For instance, review permissions for all affected users, service accounts, and systems identified in the pen test. Verify that all accounts and APIs have only the exact permissions required for their function.
- Rotate and protect credentials. Immediately rotate any potentially exposed passwords, API keys, SSH keys, or tokens to ensure security. Migrate sensitive credentials into a secure vault and enforce strong authentication in systems, such as MFA for privileged accounts.
- Harden baselines. Review system and application configurations against security baselines and apply consistent hardening templates across similar endpoints to eliminate configuration drift.
- Enable logging and monitoring. Turn on logging for identity actions, privileged commands, and authentication attempts, and integrate these logs to detect anomalies.
Once an attacker gains access, certain types of vulnerabilities can enable them to perform lateral movement and acquire privileges to disable your defense.
Step #9: Extend remediation scope to AI and LLM systems
With the EU’s AI Act set to take effect on August 2, 2026, any AI-integrated applications or agents should have their own line in the remediation program. These findings should never be combined with your general web application backlog. Prompt injection, insecure tool permissions, and model manipulation are distinct attack classes that standard pen testing often misses unless explicitly called out.
Recommended action plan:
- Scope AI systems into testing explicitly: Don’t assume that a general web app pen test will cover prompt injection, insecure tool permissions granted to agents, or model manipulation. These should have dedicated test cases
- Track AI findings in the same way as any other finding: Assign it a unique ID, owner, verifier, evidence, and retest.
- Watch access control basics first: A majority of AI-related security incidents can be traced back to ordinary access control failures.
- Map findings to the AI Act (or other applicable regulation) alongside your other compliance mappings.
Step #10: Conduct verification sweeps before closing pen test remediation
Over time, fixes can drift, updates might reintroduce vulnerabilities, or dependencies may shift unnoticed. You can curb misalignment using this workflow:
- Repeat the original testing steps, as stated in step 5, to confirm that each vulnerability remains fixed and the results match prior evidence.
- Test related systems or controls that remediation work could have potentially impacted.
- Record pass and fail rates, reopened findings, and document any new anomalies that surface.
- Reopen or escalate as needed. For example, any issues found during the sweep should be logged immediately for follow-up. Use newly gathered insights to refine your hardening strategy for the next cycle.
Running a final verification sweep before your 90-day strategy ends ensures that every closed finding remains fixed.
Step #11: Publish evidence packets to support pen test remediation strategy
A monthly one-pager evidence packet serves as a client-facing proof of your penetration testing remediation workflows. With NIS2 and DORA both in active enforcement, the packets shouldn’t just summarize; they should map directly to the frameworks that auditors or regulators will check against.
Recommended action plan:
- Summarize key metrics: Include counts of open and closed findings, risk burn-down trends, and any exceptions and reopened vulnerabilities.
- Link evidence to findings: Reference validation artifacts collected throughout remediation, ensuring every data point traces back to its unique ID for auditability.
- Map evidence to the applicable framework: For NIS2, this typically means demonstrating structured testing and remediation under Article 21. For DORA, note the distinction between routine remediation evidence and Threat-Led Penetration Testing under TIBER-EU. For PCI DSS 4.0 or ISO 27001, cite the specific control each piece of evidence satisfies.
- Include next month’s strategy: Outline what’s coming in the next remediation wave, such as verifications, design reviews, or hardening strategies.
- Maintain a consistent format: Keep packets easily readable by using the same format consistently. This makes your report repeatable, making it easy to generate and compare across quarters.
Sample automation touchpoint for penetration testing remediation
Automation supports pen testing remediation steps by speeding up workflows while maintaining consistency, accountability, and evidence across your 90-day cycle.
- Schedule nightly jobs to sync findings, including KEV and EPSS updates, from trackers, update burn-down charts, and check exception expiration dates.
- Automatically flag missing validation artifacts or exceptions nearing due dates.
- Set weekly scripts to probe high-risk classes and confirm that fixes still hold.
- Send new test results and logs to centralized evidence repositories.
Leverage NinjaOne to automate pen testing roadmap procedures
NinjaOne streamlines penetration testing remediation workflows by automating evidence collection, tracking, and reporting across your 90-day strategy. Its tools automate validation, documentation, and vulnerability management, reducing manual technician effort without compromising your client’s security posture.
- Discovery: Use policy-scheduled tasks to automate evidence collection, tag assets by finding ID, and attach monthly evidence packets to documentation. NinjaOne’s Scheduled Reports feature can automatically collect and distribute evidence across tenants, while IT asset tagging tracks and organizes endpoints across client environments.
- Prioritization: NinjaOne’s vulnerability management service surfaces vulnerabilities with their CVE and CVSS scores, and layers in KEV status and exploit context so technicians can prioritize what actually needs immediate attention rather than working down a raw severity list.
- Mobilization: Patch automation can be reconfigured to deploy stable patches or flag urgent ones that need immediate attention, connecting pen test findings directly to remediation.
- Documentation tool: NinjaOne Documentation enables you to create custom remediation runbooks and store per-tenant evidence in a centralized knowledge base. This ensures consistent workflows and facilitates easier knowledge transfer among technicians.
Standardize remediation workflows for scalable vulnerability assessment.
Build a 90-day pen testing roadmap to remediate risks
Maximize penetration tests by taking action on findings in a structured manner that preserves changes with evidence. By standardizing your findings, planning in waves, consistently validating fixes, documenting exceptions, and transparent reporting, you can reduce real risk within 90 days while maintaining stakeholder confidence.
Related topics:

