CIS Safeguard 18.3: remediate pen test findings

What CIS Safeguard 18.3 asks you to do with penetration test findings

An assessor or customer asking about penetration testing rarely wants to see the report alone. They want proof that the findings were fixed, or consciously accepted, under a process the organization already runs. Safeguard 18.3 asks for exactly that: penetration test findings remediated under the enterprise's documented vulnerability remediation process, with a timeline and level of effort set by each finding's impact and priority. The safeguard does not ask for every finding to be closed on a fixed date. It asks that the decision for each finding be made through a documented process and then carried out, so a reader can trace the path from finding to outcome.

Safeguard 18.3 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. It is assigned to the Network asset class and the Protect security function. The Assessment Specification treats 18.2, the periodic external penetration test, as a prerequisite, so the organization should confirm that tests are producing findings in a consistent form before it measures remediation. The measure itself is a compliance share: the proportion of vulnerabilities from the initial test that have been remediated or are still within scope. Confirm the exact measure and its wording in the Assessment Specification before you build a tracking report around it.

Remediation usually breaks down in three places. Findings are delivered as a PDF and never routed to an owner who can change the system. Severity is disputed between the tester, the application team and the risk function, so nothing moves while the argument continues. And the finding has no durable link to its eventual closure, so nobody can show which fix addressed which issue. A practical check is to ask for one finding from the last test and trace it: who received it, what priority it was given, which ticket tracked the fix, and what evidence shows it closed or accepted. If that trace takes more than a few minutes, the process needs work before the next assessment.

Which findings, systems, teams and providers fall under Safeguard 18.3

Safeguard 18.3 applies to the penetration test findings your enterprise produces and must remediate under its documented vulnerability remediation process. The decisions below determine which findings enter that process, which systems and teams own them, and when an outside party must be part of the work.

External tests under 18.2

The core input is the output of external penetration tests run under Safeguard 18.2. The CIS Controls Assessment Specification lists 18.2 as a prerequisite for measuring 18.3, so an enterprise with no external test history has no baseline against which remediation can be scored. Confirm that each external test report is logged with its date, scope and tester, and that every finding is recorded in the remediation tracker rather than kept only in the report PDF.

Internal and application tests

Penetration tests run by the enterprise that fall outside 18.2, such as application tests under Control 16 or internal tests under Safeguard 18.5 for IG3, also produce findings that the remediation process should cover. Decide in writing which test types feed the same remediation workflow so that findings from different tests are prioritized on one scale. Ask whether a finding from an internal test is treated with the same deadlines as an external one, and document the answer.

Network asset class scope

CIS assigns Safeguard 18.3 to the Network asset class, so the findings that a 18.3 measurement tracks should trace back to network-reachable systems, devices and services. Map each test's targets to asset inventory records from Control 1 and Control 2, and flag any tested system that is missing from the inventory. Findings on systems with no inventory record are hard to assign an owner or a deadline, and they often remain open.

Remediation owners

Remediation work is usually split between infrastructure, application, cloud and network teams, so the process must name an accountable owner for each finding before the remediation clock starts. Assign owners in the ticketing system, track decisions to accept or defer a risk, and confirm who signs off that a fix was verified. Without named owners, the compliance measure of closed or in-scope findings has no clear source.

Providers that host or tested the systems

A third party must be included in the scope when it hosts, operates or administers tested systems, or when it performed the penetration test itself. Its contracts should state who fixes which finding, how fixes are reported back, and how quickly. Control 15 covers provider assessment in general, and the provider's remediation commitments should be recorded alongside the enterprise's own findings so that no open item sits with a party nobody is tracking.

IG1 exemption and IG2 start

Safeguard 18.3 is assigned to Implementation Group 2 and 3, so an enterprise scoped only to IG1 does not carry it. IG2 and IG3 enterprises do, and should confirm which external tests have already run. Because 18.2 must be in place for 18.3 to be measured, an IG2 enterprise that has never tested externally should begin there. Confirm your Implementation Group status with your own risk assessment before scoping this Safeguard out or in.

How an assessor tests Safeguard 18.3 and what they ask for

This table compares what an assessor does, what evidence they request and where organizations usually fall short when testing Safeguard 18.3. Read each row as a step in the assessment, with the right-hand column showing what to have ready before the assessor arrives.

Assessment area	What the assessor does	What to have ready
Measured metric	Applies the Compliance metric in the CIS Controls Assessment Specification: the share of vulnerabilities from the initial penetration test that are successfully remediated or still within scope.	A count of findings from the initial test, and how many are closed, open or formally scoped out at the assessment date.
Sampling	Selects findings from the most recent penetration test and checks the population of findings the test produced, not only the ones the team chose to show.	A complete findings list from the latest test, with a stable ID for every finding.
Traceability	Traces each sampled finding to a ticket, change record or remediation task, then to the verification step that confirmed the fix.	Links from each finding ID to its ticket, change and retest result, kept in one system of record.
Process and timelines	Checks that remediation follows the documented vulnerability remediation process and that timelines and effort were set by impact and priority.	The current remediation procedure, severity or priority scheme, and target timelines by priority level.
Open items	Confirms that findings still open are covered by an accepted risk, compensating control or scope decision, approved by the right owner.	Risk acceptance records with owner, rationale, expiry date and any compensating controls.
Prerequisite check	Confirms that the penetration tests behind the findings were run under Safeguard 18.2, which the specification lists as a prerequisite for measuring 18.3.	Test reports, tester qualifications and scope documents for each test in the assessment period.
Common finding: missing IDs	Cannot match report findings to remediation records because findings lack stable identifiers.	Assign each finding a unique ID in the report and carry it into every ticket.
Common finding: no timelines	Finds remediation tickets with no target date or priority, so the assessor cannot judge whether effort matched impact.	Set and record a target date and priority on every finding at intake.
Common finding: no closure evidence	Finds findings marked closed with no retest, change record or verification, so closure cannot be confirmed.	Attach retest results or change approvals to each closed finding before closing the ticket.

Evidence that passes a Safeguard 18.3 review

An assessor testing Safeguard 18.3 looks for a chain of records: each penetration test finding traced from report to documented process, owner, fix, change and retest. The cards below describe the artifacts that make up that chain and how to keep them current between assessments.

Penetration test report with finding identifiers

The report is the starting point for the measurement, because the Compliance metric counts remediated or in-scope vulnerabilities from the initial findings. Each finding needs a stable identifier, affected asset, severity and the test that produced it, so later records can point back to it. Check that the report comes from the qualified party that performed the Safeguard 18.2 external test, and that the findings list is complete rather than a summary.

Documented vulnerability remediation process

This is the written process that sets how long each finding may stay open and how priority is assigned. Assessors check that the timelines and level of effort follow from impact and priority, and that the process is the one the team actually follows. Confirm it names the approvers, the escalation path for overdue findings, and who can accept risk on the enterprise's behalf.

Tickets with owner, due date and status

Each finding should have a ticket that records an accountable owner, a due date set under the remediation process, and a status that moves from open to closed with dated entries. A ticket with no owner or a due date that changed without a reason is a common gap. Open tracking tools such as GLPI or Zammad can hold this record, provided their history is kept and not overwritten.

Change records linking fixes to findings

Change records show how a fix reached production, which is the link an assessor needs between a closed ticket and an actual change to the system. Each change should cite the finding identifier, the approver, the implementation date and the rollback plan. Records that name a finding but show no approval or deployment date will not establish that the fix was applied.

Retest and validation results

Closing a ticket does not prove the vulnerability is gone, so retest results are the evidence that the fix worked. Keep the rescan or retest output, the date it ran and the finding identifier it confirms. Where a fix fails validation, the record should show the ticket reopened rather than closed. Scanner output from Greenbone or the retest report from the penetration tester can serve this purpose if it names each finding.

Register of accepted and out-of-scope findings

Some findings will not be fixed, and assessors expect those decisions to be visible. The register lists each accepted or out-of-scope finding with the reason, the compensating controls, the named risk owner, the approval and a review date. Without this register, findings that remain open look like missed deadlines. Confirm with your own risk owners how acceptance authority is delegated before the first review.

How remediation closes the loop from report to retest

Remediation of penetration test findings works as a loop, and an assessor will look for evidence at every step. A finding is first imported into the enterprise's vulnerability or findings register, where duplicates of the same weakness are merged. Each finding is then triaged by impact and priority under the documented vulnerability remediation process, assigned to a named owner, and given a due date that the process sets. The owner fixes the weakness through the normal change control path, so the fix is traceable to a ticket, an approver and a deployment record. The loop closes only when the finding is retested or otherwise validated and then recorded either as closed or as formally accepted with a named risk owner and an expiry date. Tools such as DefectDojo can import findings from more than 500 report formats and deduplicate them with per-tool hashcode fields, and a ticketing system such as GLPI or Zammad can carry the change record, but the tool choice does not change the process. Confirm with your own tester which report format they deliver and whether it produces stable finding identifiers.

The Compliance metric in the CIS Controls Assessment Specification compares the vulnerabilities found in the initial penetration test with their state later, so the same weakness must keep one identifier across every test cycle. If a retest creates a new record for an unchanged issue, the register shows one finding closed and one new finding open, and the metric cannot show what was actually remediated. Keep the original identifier, link each retest result to it, and record the reason for any change in its severity or scope. Reopened findings deserve the same care. When a fix fails retest or regresses after a later deployment, the finding should return to open status with its history intact, so the reviewer can see that the weakness was once closed and why it came back. Hiding reopened items in a new record is one of the most common ways that remediation evidence stops being credible to an assessor.

Decide before the next test cycle who may accept a risk, how long an accepted finding stays accepted and how reopened findings are escalated. Those three decisions determine whether the register can support the metric, and they belong in the documented process that the assessor will read first. Ask your implementation partner to show, on a sample finding, how it moves from import to triage, owner, change, retest and closure, and check that each step leaves a record you could hand to an independent assessor without explanation. The exact timelines and effort levels are for your organization to set from its own impact and priority scheme, and should be stated in that process rather than inferred from a tool default.

How to implement Safeguard 18.3 in sequence

This sequence turns penetration test findings into a documented, owned and tracked remediation cycle that can be measured against the Compliance metric in the CIS Controls Assessment Specification. Each step produces an artifact an assessor can inspect.

Confirm the 18.2 external test cadence
Safeguard 18.2 is a prerequisite for measuring 18.3, so the first step is confirming that external penetration tests run on the cadence your program sets and that a qualified party performs them. The security lead confirms the test dates, scope statements and the tester's engagement letters, then records them in a test schedule. Done means every test that will generate findings has a dated report on file and a named owner, so no finding enters the register without a traceable source.
Write the vulnerability remediation process
Write or update the documented vulnerability remediation process so it sets remediation timelines by impact and priority, the way Safeguard 18.3 requires. Security leadership defines the priority scale, the timeline for each level, the escalation path for overdue items and the approval authority for any exception. The output is a signed process document, version controlled and reviewed by the risk owner. Ask your auditor which document they will treat as the governing record before you finalize it.
Build the findings register
Create one findings register that holds every finding from each penetration test, including the test name, date, asset, impact rating, priority, owner and current status. If you import tool output, DefectDojo can ingest findings from many report formats and deduplicate them with per-tool hashcode fields, which keeps repeat findings from inflating the count. The output is a register export showing every finding from the initial test with an identifier, because the Compliance metric measures the share of those initial findings that were remediated or are still within scope.
Define ownership and routing
Assign each finding to an accountable owner for the affected system and set the routing rules that send it there. The asset owner, not the tester, decides the remediation method, and the routing rules should follow the asset classes and business units in your inventory. Record the owners in the register and in the process document. Done means every finding in the register has a named owner and every owner has confirmed acceptance of the findings routed to them.
Connect tickets to change control
Create a remediation ticket for each finding and link it to the change record that will implement the fix, so changes to production systems pass through your normal approval path. GLPI's Assistance module supports tickets, problems and changes with ITIL practices, and Zammad can route tickets from email and other channels into one system if your teams use it. The output is a sample of linked ticket and change records, traceable from the register entry to the approved change and the closing evidence.
Define the retest and accepted-risk approval path
Set how a fix is verified and how a finding can be accepted without remediation. Retesting should confirm the fix on the affected asset, ideally by the same method that found the issue, and the owner should not close a finding on their own word. Accepted risk needs a written justification, a named approver with authority over the risk, and an expiry date for review. The output is a documented retest procedure and an accepted-risk form, with the approval chain tested on at least one real finding.
Run the first closure report against the Compliance metric
Produce the first closure report using the Compliance metric from the Assessment Specification: the share of initial penetration test findings that are successfully remediated or still within scope. Count from the register export, not from memory, and show the status of each finding with its approval record. Review the report with the risk owner and record the decisions. The closed report, with the register export and approval evidence attached, becomes the baseline for the next test cycle and the evidence an independent assessor will request.

What meeting Safeguard 18.3 costs in money and effort

This table compares the main cost components of remediating penetration test findings under Safeguard 18.3, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote so that every component is priced against the same scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down and how to keep it down
Tooling or licenses	Software vendor for commercial scanners or ticketing; internal team for open-source setup	Recurring for commercial licenses; one-time for setup of open-source tools	Commercial licenses scale with assets or users. Open-source options such as DefectDojo, Greenbone Community Edition and GLPI remove license spend, but the organization still pays for hosting, patching and administration.
Engineering and team time for triage and fixes	Internal security, IT and development staff; implementation partner if engaged for remediation support	Recurring with each test cycle	Driven by number of findings, severity mix and number of systems and teams involved. Deduplicate findings in one tracker, route each finding to a named owner, and agree remediation timelines by impact and priority before the test starts.
Evidence upkeep	Internal compliance or security team; implementation partner if engaged to prepare records	Recurring	Driven by how many retest records, status changes and exception approvals must be kept for each finding. A single tracker with an audit trail for status, owner and closure date reduces manual reconstruction at audit time.
External retest or review	Qualified external tester or reviewer, paid per engagement	Recurring per test or retest cycle	Driven by scope size, number of retests needed and whether fixes must be verified by the original tester. Ask the provider to state retest scope and whether one retest round is included in the written scope.
Auditor sampling	Independent auditor or assessor, paid under their own engagement	Recurring per assessment cycle	Driven by the number of findings sampled and how complete the remediation records are. Keep finding, decision, fix and verification evidence linked so samples can be traced quickly. DeployOpen does not issue audit reports or certifications.
Exception and risk acceptance handling	Internal risk owner and management; no external fee	Recurring as findings age or are re-reviewed	Driven by the number of findings accepted rather than fixed and how often they are re-reviewed. Require a documented reason, an owner and a review date for each accepted finding.

Open-source tools that can hold remediation evidence

Safeguard 18.3 is judged on whether each penetration test finding moves through a documented remediation process with a timeline set by impact and priority. The four tools below can each hold part of that trail: the findings register, the scan record, the ticket and the request queue. None of them is a complete remediation program on its own, so the organization must decide which system is the record of truth.

DefectDojo findings register

DefectDojo is the natural system of record for penetration test findings. It imports and reimports findings from more than 500 security tool report formats through its UI or API, including the open source edition, and it also accepts a generic findings import. It deduplicates findings using per-tool hashcode fields, so a retest that reproduces an old finding updates the existing record rather than creating a duplicate. Confirm that your tester's report format is supported or can be converted, and that your retest steps map to its finding statuses.

Greenbone scan and retest records

Greenbone Community Edition (OpenVAS) is licensed under AGPL-3.0-or-later. Its gvmd service stores results in PostgreSQL, manages users and permissions, and schedules scan tasks, while users run scans and review results in the Greenbone Security Assistant web interface. For Safeguard 18.3 this gives a dated, repeatable record that a vulnerability is still present or has been closed. Confirm that its coverage matches the systems your penetration tests touched, since a scanner does not verify exploitability.

GLPI remediation tickets

GLPI is licensed under GPL-3.0-or-later. Its Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. Each finding can become a ticket with an owner, a due date set by impact and priority, and a linked change record for production fixes. Confirm that its approval, change and retest steps match your documented vulnerability remediation process before you rely on it as the audit trail.

Zammad request handling

Zammad is licensed under AGPL-3.0-only. It is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It suits remediation when tester questions, business owner replies and retest requests arrive through several channels and need one thread per finding. Check that its ticket states, escalation rules and retained correspondence give you the evidence of owner notification and closure that your process requires.

Who owns remediation, who can help, and where the auditor stops

Your organization owns Safeguard 18.3. The documented vulnerability remediation process is yours, and so are the decisions it drives. Your security lead assigns severity to each penetration test finding using your own impact and priority criteria, your system owners schedule and deliver the fixes, and an accountable executive approves any risk that will be accepted rather than fixed. The assessment measures how well this process works, so the process must be written, followed and visibly applied to the findings from the initial test.

Severity and priority decisions: Your team sets the timeline and level of effort for each finding based on impact and priority, and records the reasoning.
Fixes and change control: System owners apply the remediation through your normal change process and link each change to the finding it closes.
Accepted-risk approval: Any finding left open needs a named approver, a documented rationale and a review date.
Retest sign-off: Your team confirms that a fix worked before a finding is closed, rather than accepting a vendor's statement alone.
Ownership of evidence: Your organization keeps the records that show the process ran, since the auditor samples from your records.

Check that your remediation policy names the roles above and that someone outside the testing team can approve closure.

Where Safeguard 18.3 programs usually fall short

Most Safeguard 18.3 programs do not fail because testers miss findings. They fail after the report arrives, when ownership, priority, approval and retest records are missing. The cards below pair each common gap with a fix that an assessor can trace from the initial penetration test finding to the closed change.

Findings with no owner or due date

A finding that sits in a shared report without a named owner or due date cannot be remediated under the documented vulnerability remediation process, and an assessor has no way to measure whether it was handled. Check that every finding in the register names an accountable team, a fix owner and a target date set by its impact and priority. Ask for the register export for the last penetration test and count how many rows lack either field.

No link between finding and change

When a finding is fixed by a patch or configuration change that is not linked to the finding's record, the team can say the work happened but cannot prove which finding it closed. Track each finding to a change request or ticket, and that ticket to the commit, configuration or deployment that addressed it. In GLPI or Zammad, this usually means a ticket reference stored on the finding.

Severity set without priority rules

When testers' severity ratings are copied straight into the backlog, or each engineer decides priority case by case, remediation timelines vary with the person rather than with the documented rules. Write down how impact and exploitability combine into a priority and which deadline each priority carries, then apply those rules to every finding. Confirm that the rules sit inside the documented remediation process that Safeguard 18.3 refers to.

Accepted risks with no approval

Some findings are never fixed because someone decided the risk was acceptable, but the decision is recorded only in a chat thread or an email. An assessor testing the Compliance metric will treat unapproved exceptions as open vulnerabilities. Require a written risk acceptance for each finding that stays open, signed by the owner of the affected asset and a risk approver, with a review date. Record the acceptance in the same register as the finding.

Retests that are never recorded

Teams often fix a finding, assume it is closed, and never ask the tester or a scanner to confirm. Without a retest record, the scope of remediated and still-open findings cannot be shown at the next assessment. Keep a dated retest result for each finding, whether it came from the penetration tester, a rescan or a targeted check, and store the evidence with the finding. Prerequisite Safeguard 18.2 testing supplies the baseline these retests compare against.

Findings re-entered under new identifiers

When each penetration test is loaded as a new set of records with new IDs, the same weakness appears as a fresh finding and its history is lost. The Compliance metric compares the initial findings with their later status, so that comparison breaks. Import each test into a tool that deduplicates findings, such as DefectDojo, and keep the original finding identifier across reimports so every finding has one traceable history.

Questions buyers ask about remediating pen test findings

How much effort does remediating penetration test findings take?

The effort depends on how many findings the test produced, how severe they are, and how much of the affected estate has to change to fix them. Safeguard 18.3 asks you to set a timeline and level of effort for each finding based on its impact and priority, so the work is sized finding by finding rather than as one block. Costs have three parts: the internal time of engineers who patch, reconfigure or redesign systems; the time of whoever triages and retests; and any external help you buy. Most of the cost is one-time for the first cycle and recurs with each new test. To control it, ask your provider for a quote that lists each finding group, the systems it touches and the retest effort included.

Will an assessor test Safeguard 18.3 separately from 18.2?

Yes, the assessment approach treats them as linked but separate. The CIS Controls Assessment Specification lists Safeguard 18.2, which covers running external penetration tests, as a prerequisite for measuring 18.3. An assessor therefore looks first for evidence that the external tests happened, then for evidence that the findings from those tests were remediated under your documented vulnerability remediation process. The 18.3 measure is a Compliance metric: the share of findings that were remediated or are still within an approved scope. Keep the test report, the remediation tickets and the closure records together so the chain is easy to follow.

How long should remediation timelines be?

Your own documented vulnerability remediation process should set the timelines, not a number fixed on this page. Safeguard 18.3 expects the timeline to follow from each finding's impact and priority, so a critical finding on an internet-facing system will normally have a shorter window than a low-severity issue on an isolated host. Write the windows into the process, assign owners and record any exceptions with a reason and an approver. When you ask a provider to plan the work, ask how it maps findings to your priority scale and how it records deadlines and exceptions in your ticketing system.

Can we remediate penetration test findings in-house?

In many cases, yes. Safeguard 18.3 does not require an outside firm to fix findings, and the organization owns the remediation process and its records. The question is capacity and skill. Your team needs people who can read a tester's proof of concept, decide the root cause, change the system and prove the fix works. Open-source tools can carry the workflow: DefectDojo can import findings from more than 500 security tool report formats and deduplicate them, GLPI's Assistance module can track tickets and problems following ITIL practices, and Zammad can run a helpdesk-style ticket queue. Confirm each tool's current capabilities in your environment before you commit to a design.

What does the remediation work need from the team?

The work needs four things from the team. First, a named owner for each finding who can change the affected system. Second, a triage step that assigns impact and priority consistently, so timelines are defensible. Third, change control that lets engineers patch or reconfigure without breaking production, with rollback steps written down. Fourth, retesting by someone other than the person who made the fix, with the result recorded against the original finding. Engineers, system owners, security staff and whoever runs change management all take part. Keep the closure evidence in a single system so an assessor can trace each finding from report to fix to retest.

Does DeployOpen issue a certificate for Safeguard 18.3?

No. DeployOpen does not issue audit reports, attestations or certificates. It can help prepare systems, ticketing workflows and evidence for remediation of penetration test findings, and it runs security testing itself. Only an independent auditor or certification body can assess your implementation and issue a report or certificate. Before you engage any firm, confirm what it will deliver and who will sign the output. Your organization owns its controls, and the assessment result belongs to the independent party that performs it.

How is a fixed-scope engagement agreed before work starts?

Most DeployOpen engagements are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before work starts. For remediation support, the written scope should name the systems and findings in play, the workflow tools to be configured, the evidence to be produced, the retesting included and the responsibilities of each party. A quote follows from that written scope, because DeployOpen does not publish a price list. Ask for the scope document, a list of exclusions and a statement of what happens if new findings appear during the work. Ongoing support and continuous testing can be added as retainers if you need them.

How DeployOpen scopes and prepares Safeguard 18.3 evidence

DeployOpen works on Safeguard 18.3 as implementation and evidence preparation inside your own infrastructure. We set up the systems that track penetration test findings from intake to closure, and your organization keeps ownership of its remediation process, its decisions and its controls. Independent assessors are the parties who test and report on the Safeguard.

How we scope

The written scope names which penetration test reports feed the remediation workflow and which assets they cover.
We confirm the documented vulnerability remediation process your organization already uses, or agree what needs to be written.
The scope sets how impact and priority drive remediation timelines and effort, so the criteria are agreed before work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

We configure a ticketing or findings platform to record each penetration test finding, its owner and its target date.
Findings from testing tools are imported and deduplicated so each vulnerability is tracked once across retests.
Remediation tickets route to system owners with impact and priority fields that match your documented process.
Dashboards track the share of initial findings that are remediated or still within scope, so the Compliance metric can be reported.

How we hand over

You receive configuration records, workflow documentation and a register linking each finding to its remediation evidence.
Retest results and closure records are stored so an assessor can trace each finding from report to fix.
We document operating steps so your staff can run the workflow without ongoing outside help.
Your organization decides which findings are accepted, deferred or closed, and holds those decisions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover platform upgrades, workflow changes and periodic reviews of open findings and their timelines.
Ask any provider to confirm which of these items are in the written scope and which are optional retainer work.
Confirm with your independent assessor which evidence formats they expect before the first assessment cycle.