What Safeguard 7.7 asks you to remediate, and how often
If your enterprise is an IG2 or IG3 organization preparing to show CIS Controls v8.1 coverage, Safeguard 7.7 requires that detected software vulnerabilities be remediated at least monthly, through processes and tooling that follow the remediation process written under Safeguard 7.2. The Safeguard sits in the Software asset class and the Respond security function, and it applies from IG2 upward, not at IG1. The risk it addresses is simple: a known flaw that stays unfixed remains exploitable, and attackers routinely target published weaknesses in software long after the fix exists. The assessor will not only ask whether you run scans. They will look for evidence that findings move through a defined path to closure within the monthly window.
Start by confirming who owns each step. Vulnerability findings usually come from scanners, application testing and vendor advisories, but the fix sits with infrastructure, application or product teams, each with its own change calendar. Ownership gaps and an unclear priority order are the most common reasons a backlog grows. Before measuring anything, check that your Safeguard 1.1 asset inventory is current, because the assessment specification treats it as a prerequisite for measuring Safeguard 7.7. Then confirm that the remediation process from Safeguard 7.2 names owners, risk-based priorities and target timeframes for each severity, and that it is reviewed at least monthly.
The assessment specification defines four measures for Safeguard 7.7, combined into one remediation metric, so plan to produce data for each: when a finding was detected, when it was remediated or formally accepted, which asset and software it affects, and whether the remediation happened within the monthly cycle. Open-source tools can hold this record. DefectDojo can import findings from many scanner formats and deduplicate them, giving you one timeline per finding. Confirm the import formats and reporting features you need against the current documentation and your own scanner outputs before you commit to a design. Plan for an independent assessor to test the records you produce, not the summary slides.
Which systems and teams fall under Safeguard 7.7
Safeguard 7.7 applies to detected software vulnerabilities, so the first job is deciding which assets, software and owners that finding and fixing covers. Each card below is a scoping decision that changes how much work the remediation process creates and how the measurement is built.
Enterprise assets and software in scope
Decide which devices, servers, cloud workloads and applications the remediation process covers. Start from the Safeguard 1.1 asset inventory, because the CIS assessment specification treats it as a prerequisite for measuring Safeguard 7.7. Anything missing from the inventory, such as a forgotten test server or a SaaS integration, will not appear in the remediation metrics. Ask whether each asset class has a named owner and a scan source.
Platform team ownership
Platform engineering usually owns operating systems, container hosts, network devices and the shared middleware beneath applications. Agree in writing who patches each layer and who verifies the result. Where the platform team deploys fixes but an application team owns the workload, the handoff point should be explicit, or findings will sit between two queues. Record the owner for each finding in the tracker.
Application team ownership
Application teams own the libraries, frameworks and code dependencies their services ship with. Their remediation work is often the largest share of detected software vulnerabilities, so the remediation process must reach them with clear priorities and deadlines. Confirm that each application has a named owner, that dependency findings route to that owner, and that the team can show a fix or a documented exception.
Third-party vendor responsibilities
Vendor-managed software, appliances and hosted services often cannot be patched by your team. Decide which vendor contracts require timely fixes, how you receive vendor advisories, and what you do when a vendor is slow. Record the vendor as the remediation owner, track the open finding, and keep the vendor's response as evidence. Review these obligations alongside your service provider management practices.
Exceptions and risk acceptance
Some vulnerabilities cannot be fixed within the monthly cycle because a patch breaks a critical process or no fix exists. Define who may approve a deferral, the maximum period an exception may run, and the compensating controls required meanwhile. Each accepted risk should be recorded with its approver and review date. Undocumented exceptions are the most common reason a remediation metric looks better than the real state.
Severity thresholds and remediation priority
Decide which findings trigger immediate action and which follow the monthly cadence. Base priority on the remediation strategy from Safeguard 7.2 rather than on scanner scores alone, and account for whether a flaw is exposed to the internet or to sensitive data. Confirm that the thresholds are written down, that the scanner and ticketing system use the same severity labels, and that findings above the threshold have a deadline.
How an assessor measures remediation against the CAS
The assessor starts by confirming that a written remediation process exists and that it describes how detected software vulnerabilities are fixed. The Assessment Specification states what to measure, not how, so the document is judged on whether it sets out the steps, owners, priorities and cadence that the organization actually follows. Because Safeguard 7.7 builds on the process from Safeguard 7.2, the assessor expects the document to show a risk-based approach and a review at least monthly.
- Named ownership: The document names the roles that triage findings, approve fixes and track deadlines.
- Risk-based priorities: It explains how severity, exposure and asset importance set the order of work.
- Defined cadence: It states that remediation runs at least monthly and what triggers an out-of-cycle fix.
- Tooling references: It identifies the scanners, ticketing systems or patch tools that carry work from detection to closure.
- Version and approval: It shows an owner, an approval date and a revision history.
Confirm that the document matches what teams do in practice, because an assessor will compare it with the records in the other tabs.
The second check looks at the vulnerability data itself. The assessor wants to see that software vulnerabilities are detected, recorded against specific assets, and fixed within the monthly cycle the process defines. This is where the asset inventory from Safeguard 1.1 matters, since the assessor needs to tie each finding to a known enterprise asset to judge whether it was handled.
- Complete asset linkage: Each finding maps to an asset in the inventory, so no vulnerable system falls outside the count.
- Detection dates: The record shows when each vulnerability was first detected.
- Remediation dates: The record shows when each fix was applied or verified.
- Monthly timing: The assessor checks whether findings are closed within the defined remediation cycle.
- Recurring findings: Repeat detections on the same asset are noticed and explained.
Confirm that your scanner export and ticketing data can be filtered by asset, detection date and closure date without manual reconstruction.
The third check asks whether remediation actually happened and can be proven. An assessor looks for records that show a fix was applied, a configuration changed, or a compensating action taken, and that the record ties back to the original finding. Records that exist only as verbal confirmations usually fail to satisfy the measure.
- Fix evidence: Patch logs, change tickets or configuration records show the remediation step.
- Verification rescans: A later scan or check confirms the vulnerability no longer appears.
- Traceable links: Each change ticket references the finding it closes.
- Consistent status: Finding statuses in the scanner and the ticketing system agree.
- Retained history: Records are kept long enough for the assessor to sample past periods.
Ask your assessor which sample periods and record types they intend to test before the assessment starts.
Not every vulnerability can be fixed within the cycle. The assessor examines how exceptions are approved, documented and reviewed, because an unmanaged exception is a silent gap in the metric. The check focuses on whether deferrals are deliberate, time-limited and visible to people who can accept the risk.
- Documented reason: Each deferred finding records why the fix cannot happen on schedule.
- Approval authority: A named role accepts the risk, and that role is recorded.
- Expiry and review: Exceptions carry an end date and are revisited before it passes.
- Compensating controls: Where a fix is delayed, the record describes the interim measure and its verification.
- Reporting: Open exceptions appear in management reporting, not only in a spreadsheet.
Confirm how your organization counts exceptions in the remediation metric, since the assessor will ask how they affect the result.
Implementing monthly remediation in five steps
This sequence turns detected software vulnerabilities into tracked, verified fixes on a monthly cycle, with each step producing a record an assessor can sample. It starts from the remediation process already written under Safeguard 7.2 and ends with evidence that fixes held and exceptions were approved.
Confirm the remediation process and monthly review
Start by checking that the risk-based remediation process from Safeguard 7.2 is written, approved and reviewed at least monthly. The process should name who owns remediation, who approves exceptions and which systems it covers. Your team confirms this with the process owner and the approver. The step is done when you hold a dated, approved version of the process and a record of the most recent monthly review that an assessor can sample.
Build one vulnerability register
Feed findings from your vulnerability scanners and patch tools into a single register so each software vulnerability appears once, with its asset, source tool and status. Open-source platforms such as DefectDojo can import reports from many scanner formats and deduplicate findings using per-tool hashcode fields, which keeps duplicate tickets out of the cycle. Confirm the import and deduplication behavior against your own scanner outputs before relying on them. The step is done when a sample of findings traces back to the original scan result.
Set severity and due-date rules
Agree the rules that decide which findings get fixed first and by when, based on the risk-based strategy in your remediation process. Map severity scores, asset criticality and exposure to priority levels, and document the due-date rule for each level. Safeguard 7.7 does not set these deadlines itself, so ask your assessor and your own risk owners to confirm the thresholds are reasonable for your environment. The step is done when the rules are approved and applied to the register.
Run the monthly remediation cycle
Each month, select the findings due in the cycle, assign them to owners and open a tracked ticket for each fix or grouped fix. Owners apply patches or configuration changes, record the change reference and move the ticket through review. Changes should follow your existing change management process. The step is done when every in-scope finding has a ticket with an owner, a status and a recorded outcome, including items deferred for a stated reason.
Verify fixes and approve exceptions
Rescan the affected assets after changes are applied, or confirm the fix through the patch tool's reporting, and close a ticket only when the vulnerability no longer appears. Any finding that cannot be fixed in the cycle needs a documented exception with a risk acceptance, a named approver and a review date. The step is done when verification results are attached to each closed ticket and every open exception has an approval on file, ready for the monthly review in the first step.
Evidence that shows monthly remediation happened
Safeguard 7.7 is tested on a record of fixes, not on a policy statement. The cards below cover the artifacts an assessor will ask to see and how to keep them current between assessments, so that a monthly remediation cycle can be shown for any month in the review period.
Approved remediation process and review record
The remediation process from Safeguard 7.2 is the rule that Safeguard 7.7 applies. Keep the approved version, its owner, and a dated record of the review that happened at least monthly. Check that the document names the risk criteria, the remediation timeframes, and who approves exceptions. An assessor will compare the process with the tickets, so any gap between the written cadence and the actual cycle will show up quickly.
Findings register with detection dates
The findings register is the starting point for measuring remediation. Each software vulnerability needs a record with the asset, the affected software, the detection date, and the source scan. Deduplicate findings so one defect is not counted several times. Confirm that every finding can be traced back to a scan run, because a register built from manual edits will not survive review.
Remediation tickets with closure dates
Each finding that is fixed should map to a ticket that records the change made, the owner, and the closure date. Closure should happen only after the fix is applied, not when the ticket is opened. Check that tickets for the same month can be matched to findings detected in that month or earlier, so the remediation rate for each cycle can be calculated from the records alone.
Verification scan results
A closed ticket is not evidence on its own. Rescan the affected assets after each fix and keep the results showing that the vulnerability no longer appears. Store the scan date, scanner version, and target list with each verification run. Where a fix is not verified, the finding should stay open or move to a documented exception rather than being closed on the ticket alone.
Documented exceptions with approvals
Some vulnerabilities will not be fixed within the cycle, for example where a vendor patch is unavailable or a change would break a production dependency. Each exception needs a written reason, a compensating measure, a risk owner's approval, and a review date. Keep exceptions in the same register so an assessor can see how many findings were deferred and whether each deferral was approved.
Monthly snapshots and retained scanner history
Assessors test a period, so the evidence for every month must still exist later. Export the findings register and ticket list at the end of each month and store them with a checksum. Retain scanner result history for the full review period, and record the scanner and feed versions used. Confirm the retention period with your auditor before setting the schedule, and check that exported files can still be opened in the tools that produced them.
What meeting Safeguard 7.7 costs in money and effort
The table lists each cost component of remediating detected software vulnerabilities, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request so that each line can be compared across providers. The main takeaway is that remediation labor and the upkeep of the scanner and register usually recur for as long as the software estate changes, while tooling license spend can be removed by self-hosted open-source platforms.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Scanning and findings tooling | Licence vendor, or no licence cost for self-hosted open-source tools | Recurring if licensed; setup is one-time | Number of asset classes scanned; open-source removes licence spend but not hosting or staff time |
| Findings register setup | Implementation partner or internal platform team | One-time | Number of scanner report formats to import and how many deduplication rules must be tuned |
| Register and scanner upkeep | Internal operations team or retained partner | Recurring | Frequency of scanner updates, number of scan targets and volume of new findings each month |
| Remediation engineering time | Internal engineering or patching teams, or contracted staff | Recurring | Size of the software backlog, number of software stacks and how many fixes need code or configuration change |
| Remediation process and risk decisions | Internal security and governance staff | Recurring, with a one-time drafting cost | Number of exceptions and risk acceptances that need review each cycle |
| Monthly cadence reporting | Internal security team | Recurring | Number of business units reporting and whether evidence is generated automatically from the register |
| External review or testing | Independent assessor, testing firm or consultant | Often periodic | Scope of the review, number of applications tested and whether findings are validated by a second party |
| Auditor sampling and evidence requests | Organization for preparation, independent auditor for testing | Recurring at each audit cycle | Sample sizes the auditor selects, quality of findings history and how easily records can be produced |
Who owns remediation, what partners prepare and what auditors test
Your organization owns Safeguard 7.7 in full. The Safeguard asks that detected software vulnerabilities be remediated through processes and tooling at least monthly, following the remediation process you wrote under Safeguard 7.2. Someone inside the organization must decide which vulnerabilities are fixed, by when, which are accepted or mitigated, and who signs off on exceptions. Those are risk decisions, and no partner or auditor should make them for you.
- Risk decisions: Setting remediation timeframes by severity and asset criticality, and approving exceptions with a named owner and an expiry date.
- Fixes and changes: Applying patches, configuration changes or compensating controls, and confirming they took effect.
- Process ownership: Keeping the remediation process current and reviewing it at least monthly, as Safeguard 7.2 requires.
- Accountability for results: Reviewing monthly remediation metrics and escalating overdue items to the people who own the affected systems.
- Asset inventory: Maintaining the enterprise asset inventory that the assessment specification treats as a prerequisite (Safeguard 1.1).
Confirm that a named role holds each of these duties in writing before any outside party starts work.
An implementation partner can build the machinery that produces the evidence. DeployOpen, for example, prepares systems and evidence for compliance assessments inside your own infrastructure, but the decisions above stay with you. Work is usually scoped as a fixed deliverable with written acceptance criteria, so you can see exactly what was built and handed over.
- Findings register: Setting up a central place to hold vulnerability findings from scanners, such as a DefectDojo instance that imports and deduplicates results.
- Scanner schedules: Configuring scan tasks and their cadence in tools such as Greenbone Community Edition, so scans run on the schedule your process states.
- Ticket workflow: Connecting findings to the ticketing system, with fields for owner, due date, severity and exception status.
- Evidence exports: Producing repeatable reports that show detection dates, remediation dates and open items over time.
- Documentation: Writing the runbooks that explain how the pipeline works and who operates each step.
Ask the partner to state which parts of this list it will hand over and which it will operate after handover, and who holds the administrator credentials at the end.
An independent assessor, auditor or certification body tests whether Safeguard 7.7 is met and issues any report or certificate. Only that party can do so. The assessor checks the evidence against the measures in the CIS Controls Assessment Specification for Safeguard 7.7, which defines four measures combined into a single remediation metric. The assessor will not accept a description of the process alone; it will sample findings and trace each one from detection to closure.
- Sampling: Selecting detected vulnerabilities across a period and tracing each to a fix, an accepted exception or an open ticket.
- Timeliness: Comparing remediation dates with the timeframes in your own process.
- Exception review: Testing whether accepted risks have approval, an owner and an expiry date.
- Completeness: Checking that scanned assets match the asset inventory, so findings are not missing from the population.
- Independence: Forming the opinion itself, without relying on the partner's word.
Agree the assessor and the evidence format early, because the assessor, not the implementation partner, decides whether the evidence is sufficient.
The boundary between preparing evidence and attesting to it is where many programs run into trouble. An implementation partner can configure a register and export data, but it cannot certify that your remediation met the Safeguard. Mixing those roles weakens both the partner's neutrality and the assessor's independence. Treat the partner's output as system-generated evidence, and the assessor's conclusion as the only attestation.
- Partner outputs: Configurations, runbooks, scan reports and exports, all owned by your organization after delivery.
- Assessor outputs: The formal report, opinion or certificate, issued only by the independent party.
- Shared responsibility: Data retention, access logs for the findings register, and change records for scanner configuration.
- Cost components: Partner fees cover implementation scope; assessor fees cover testing and reporting. Ask each for a separate written quote.
- Recurring work: Monthly metric reviews and scanner upkeep are usually internal, with optional retainers for ongoing support.
Before you sign, confirm in writing which party issues any report and that no partner will sign attestations on your behalf.
Where organizations fall short on Safeguard 7.7
Safeguard 7.7 asks for detected software vulnerabilities to be remediated at least monthly, through processes and tooling that follow the remediation process from Safeguard 7.2. The gaps below tend to appear in the same places: the process, the tooling, the owners, the exceptions and the proof that fixes worked.
No remediation process tied to 7.2
Many teams patch on instinct, with no written remediation strategy that sets priorities, deadlines and escalation. Safeguard 7.7 applies the process from Safeguard 7.2, so an assessor will ask which document sets the target for each severity and who signs off on it. Check that the 7.2 process names owners, timeframes and the review cadence, and that the monthly remediation work visibly follows it.
Findings scattered across tools
Scanner output, cloud security alerts and developer tool reports often sit in separate consoles, so the same flaw appears several times and nobody sees the full backlog. Consolidate findings into one register, deduplicate them, and record which tool raised each one. Open-source platforms such as DefectDojo can import reports from many scanners and deduplicate them, but confirm the formats your tools produce before you commit to a design.
No proof of monthly cadence
A team may remediate regularly without being able to show it. Assessors look for dated records of remediation cycles, such as closed tickets, change records and meeting notes, that cover each month in the review period. Set a fixed monthly remediation cycle, keep the outputs in a system of record, and check that gaps in any month can be explained.
Unowned assets
A vulnerability cannot be fixed if nobody is accountable for the asset that carries it. Gaps often sit on legacy servers, shadow applications or software installed outside the inventory. Safeguard 1.1, the enterprise asset inventory, is a prerequisite for measuring 7.7, so start by confirming every affected asset has a named owner and an entry in the inventory before you measure remediation.
Exceptions without approval
Teams often defer a fix because of a vendor dependency or a production risk and never record the decision. Each deferral should carry a documented risk acceptance, an approver with the authority to accept that risk, a compensating control and an expiry date. Review open exceptions at each monthly cycle so that deferred findings do not quietly become permanent.
No verification scan after fixes
Closing a ticket after a patch is applied does not prove the vulnerability is gone. Patches can fail silently, be rolled back or miss a component. Re-scan the affected assets after remediation, record the result next to the original finding, and reopen any finding that still appears. This check turns a closed ticket into evidence that the fix worked.
Questions buyers ask about Safeguard 7.7
Do IG1 organizations have to meet Safeguard 7.7?
No. CIS Controls v8.1 assigns Safeguard 7.7 to Implementation Groups 2 and 3, so an organization that only meets IG1 is not measured against it. IG1 covers essential cyber hygiene and includes the vulnerability management and patching basics that come before this Safeguard. Organizations that fall under IG2 or IG3 because of their size, data sensitivity or regulatory exposure should treat 7.7 as in scope. Confirm your Implementation Group against the CIS Implementation Groups pages before you scope the work, since the group determines which Safeguards your assessor will test.
How much effort does Safeguard 7.7 take, and what drives it?
The effort depends mostly on how many software products are in scope, how many vulnerabilities your scanners report each cycle, and how much of your patching already runs automatically. Organizations with a current software inventory and a remediation process usually spend less time triaging findings than those working from spreadsheets. The main cost components are internal staff time for triage and change approval, the tooling that tracks findings, and any external help. Ask any partner for a fixed-scope quote that lists the asset count, the scanners in use, the number of applications and the reporting you expect.
Can we meet Safeguard 7.7 in-house?
Many organizations can, provided they have people who own the vulnerability process, a working scanner feed and change windows that allow patches to be deployed. The work becomes harder when scan results live in several tools, when no one owns the link between a finding and the system that must be fixed, or when the team lacks evidence habits. An implementation partner can set up the workflow and evidence trail, but the organization keeps ownership of its controls and of every remediation decision. Independent assessors, not partners, decide whether the Safeguard is met.
How long does preparation for Safeguard 7.7 take?
The timeline depends on the factors that shape the work rather than on a fixed duration. The main drivers are the state of your asset and software inventory, whether a remediation process from Safeguard 7.2 already exists, how many environments and business units must be covered, and how much tooling must be installed or integrated. Organizations with clean inventories and existing scan programs usually move faster. Ask for a written schedule with milestones tied to the deliverables agreed in the scope, and confirm which items depend on your change board or procurement timing.
What does the work need from our team?
Your team needs to supply four things: access to systems and scanners, named owners for software and applications, a change process that can schedule fixes, and someone who can approve risk acceptances when a fix is not possible. Asset owners must confirm which products they run and which versions are supported. Security staff must agree on severity thresholds and remediation deadlines that match the remediation process. Without these inputs, findings pile up without an accountable owner, and the measurement that the assessment specification calls for becomes difficult to produce.
How does Safeguard 7.7 map to NIST SP 800-53 RA-5 and SI-2?
The CIS Controls Navigator for v8.1 links Safeguard 7.7 to NIST SP 800-53 Rev. 5 control RA-5 (vulnerability monitoring and scanning) and to SI-2 (flaw remediation), along with RA-5(2) and RA-7. In practice, RA-5 asks for scanning and monitoring of vulnerabilities, while SI-2 asks for flaws to be identified, reported and corrected. The same evidence you collect for 7.7, such as scan results, remediation tickets and closure records, can support both controls. Treat the Navigator as a starting point and confirm the exact mapping and its scope against the current version of NIST SP 800-53 with your assessor.
How does Safeguard 7.7 relate to PCI DSS requirement 11.3?
The CIS Controls Navigator links Safeguard 7.7 to PCI DSS v4.0 requirements 11.3.1, 11.3.2 and 11.3.2.1, which cover internal and external vulnerability scanning and the handling of findings. Organizations assessed against PCI DSS will need quarterly scan evidence and proof that high-risk findings were addressed, and Safeguard 7.7 supplies the process discipline behind that proof. Scanning requirements under PCI DSS have their own rules for who may perform scans and what counts as a passing result, so confirm those with your qualified assessor or approved scanning vendor before relying on internal scans for payment account environments.
Which open-source tools can produce the remediation evidence?
DefectDojo can import and reimport findings from more than 500 security tool report formats, including in its open source edition, and it deduplicates findings using per-tool hashcode fields. That helps when several scanners report the same flaw. Greenbone Community Edition (OpenVAS) runs vulnerability scans, stores results in PostgreSQL and schedules scan tasks through its Greenbone Security Assistant interface. Together they can show what was found, when it was found and whether it is still open. Confirm each tool's current capabilities and license terms in your own environment before you commit to a design.
How DeployOpen prepares remediation evidence for Safeguard 7.7
DeployOpen plans, implements and documents the open-source tooling that supports Safeguard 7.7 inside your own infrastructure, so your team can show detected software vulnerabilities being remediated at least monthly. We prepare systems and evidence; your organization owns the remediation process and any certification or attestation comes from an independent assessor.
How we scope
- We agree a written scope covering which software assets, scanners and ticketing sources feed remediation tracking.
- We confirm the remediation process from Safeguard 7.2 and the monthly cadence it sets before any build begins.
- We define the evidence each measure in the CIS assessment specification will need, and who in your organization signs off on it.
How we build
- We deploy DefectDojo to import and deduplicate findings from the scanners you already run, using per-tool hashcode fields.
- We configure Greenbone Community Edition with PostgreSQL storage and scheduled scan tasks so results are recorded consistently.
- We link findings to owners, due dates and status changes so remediation activity can be traced back to each detected vulnerability.
How we hand over
- We document the configuration, data flows and roles so your team can run the tooling after handover without us.
- We deliver reports that show findings opened, assigned, remediated and reopened, mapped to the measures in the assessment specification.
- We walk your team through how to export records for an independent assessor, who decides whether the evidence is sufficient.
How we support
- Fixed-scope engagements end with written deliverables, so changes after handover are agreed in a separate written scope.
- Ongoing support, upgrades and continuous testing are available as a retainer if your team wants help keeping the tooling current.
- Ask any partner to confirm in writing which Safeguard 7.7 evidence they prepare and which parts remain with your team or your assessor.
