Safeguard 7.2 remediation process: requirements and evidence

What a remediation process must say before any patch ships

An auditor or customer has asked for proof of a remediation process, and your team already has patching tools and scanners but no written strategy. Safeguard 7.2 asks for a written remediation process that sets out a risk-based strategy for fixing vulnerabilities, and that the process is reviewed at least once a month. The Safeguard sits in the Govern security function and the Documentation asset class in CIS Controls v8.1, which reflects its purpose: it decides how fixing happens before any tool runs. It is an IG1 Safeguard, so every enterprise is expected to have it, whatever its size. Unlike Safeguards 7.3 and 7.4, which automate operating system and application updates, or 7.5 and 7.6, which schedule scans, Safeguard 7.2 produces no technical output of its own. It is the written rulebook that Safeguard 7.7 then applies to each detected vulnerability.

The risk it addresses is ad hoc remediation. Without a stated strategy, teams fix whatever the scanner or a senior manager flagged most loudly, while exposed internet-facing systems wait behind internal findings of lower impact. The process must say how risk is judged (for example, asset criticality, exposure, exploit availability and data sensitivity), and who decides when those factors conflict. Pure severity scores from a scanner are an input, not the strategy, so the document should state how scanner output is adjusted before it becomes a work item.

Three problems usually make this hard. First, ownership gaps: the document names no accountable owner for each asset class, so findings bounce between security and infrastructure teams. Second, scanner output with no priority rules, so the backlog grows faster than anyone can triage it. Third, reviews that lapse. The assessment specification scores Safeguard 7.2 as failing when no process exists or when it was last reviewed more than 30 days ago, so a monthly review must be scheduled, owned and recorded. Confirm the review cadence and evidence format with your assessor before the first audit cycle.

Which assets, teams and vendors a remediation process must cover

Safeguard 7.2 is only as complete as its scope. The decisions below determine which assets the strategy governs, who owns each fix and where responsibility passes to an outside party, so each one should be settled in writing before the process is approved.

Asset classes the strategy governs

Safeguard 7.2 sits in the Documentation asset class, but the remediation strategy it requires has to reach every asset class that can carry a vulnerability: Devices, Software, Data, Users, Network and Documentation. Check whether the written strategy names each class explicitly or assumes that scanners will cover them. A process that only addresses servers and endpoints leaves network appliances, SaaS configurations and data stores without a documented route to a fix.

Platform team ownership of fixes

The platform team usually owns operating system images, container base images, hypervisors and the shared services that deploy patches. Its remediation timelines should be written into the process so that a finding on a shared component does not wait for an application owner to act. Confirm who approves emergency changes to shared platforms and who can roll back a patch that breaks a service.

Application team ownership of fixes

Application teams own the libraries, frameworks and code that their services depend on. The process should state how a finding in a third-party component is routed to the team that maintains the dependency, what counts as a fix (an upgrade, a configuration change or a compensating control) and who signs off on accepting residual risk. Without that routing, findings often sit in a shared queue that no team recognizes as its own.

Network team ownership of fixes

Network teams own firewalls, routers, load balancers, VPN concentrators and wireless controllers, which often run firmware that the vendor patches on its own schedule. The process should name the owner for each device family, the maintenance window used for firmware changes and the route for vulnerabilities that the vendor has not yet fixed. Confirm that these owners appear in the same review cycle as the server and application owners.

Third-party and externally managed systems

Systems run by a managed service provider, a SaaS vendor or a cloud platform may fall outside direct patching, yet the organization remains accountable for the risk they carry. Decide whether each external system is in scope for the remediation strategy, who requests fixes from the provider, and what evidence the provider must supply. Put the response obligations in the contract, because a finding that the provider does not fix within the agreed route is still an open finding on your register.

How an assessor tests the remediation process against the 30-day rule

This table lists the steps an assessor takes to test Safeguard 7.2, from confirming the written process exists to checking sign-off and whether teams follow it. Read each row as a test the organization should rehearse before an assessment, with the common findings showing where evidence usually falls short of the 30-day review threshold.

Test step	What the assessor requests	Common findings
Confirm a written remediation process exists	The current remediation process document, with its version history and the location where staff can access it	Remediation practice is described only in tickets or chat, with no single document that sets out the process
Confirm the process names a risk-based strategy	Sections showing how vulnerabilities are prioritized by risk, such as severity, asset importance and exposure, and the timeframes tied to each level	Priority is set only by the scanner's severity score, or the document says 'fix critical issues' without defining what counts as critical
Check the recorded last review date	The review date on the document and the record of the most recent review, compared with the date of the assessment	The document shows a review date older than 30 days, or the review was done but not recorded in the document
Test the 30-day threshold over the period	Review records or revision history covering the assessment period, to confirm reviews happened at the required interval, not just once	A single review date appears on the document, but earlier reviews cannot be shown, so the interval cannot be verified
Sample recent vulnerabilities	A selection of recently detected vulnerabilities with their risk rating, assigned owner, target date and closure or exception record	Tickets exist, but priority and target dates do not match the strategy written in the process
Compare roles and priority rules with practice	The named roles, the escalation path and interviews or walkthroughs with the people who triage and fix findings	Teams use a different priority scheme, or the named owner has left and no one has been reassigned
Check exceptions and risk acceptance	The list of deferred or accepted vulnerabilities, the approver and the stated reason and review date	Exceptions are granted informally, or accepted risks never return for review
Check review sign-off	Evidence that an accountable owner approved the process and each review, such as a signed record or an approval in a controlled system	No approver is named, or sign-off comes from the same person who maintains the process with no independent check

How to write and maintain a remediation process in six steps

This sequence turns Safeguard 7.2 into a working, owned document that sets risk-based fix, mitigate and accept paths, hands clear work to Safeguard 7.7 and is reviewed on a recorded monthly cadence.

Name an accountable owner and approver
Assign one named owner who answers for the remediation process, usually a security operations, vulnerability management or GRC lead, and name the approver who signs off on risk acceptances. Write both names into the process document and confirm the owner has authority over the teams that patch systems, because a process nobody can enforce will not pass review. Done means a signed or approved document header with owner, approver and effective date, and the owner has accepted the role in writing.
Define the risk inputs for prioritization
Decide which factors place a vulnerability in a priority tier: asset criticality, exposure (internal or internet-facing), exploitability (including whether exploit activity is known), and data sensitivity of the systems involved. Write a short definition for each input so two analysts score the same finding the same way. Involve system owners and the data owners named under your data management process. Output: a written list of inputs with definitions and the data source for each, such as the asset inventory and classification records.
Build the priority matrix and remediation paths
Combine the risk inputs into a small set of priority tiers, for example a matrix that maps exposure and criticality to a tier. For each tier, define the remediation path: fix (apply a vendor patch or configuration change), mitigate (apply a compensating control while a fix is pending), or accept (record a time-limited risk acceptance signed by the approver). Specify what evidence each path must leave behind. Output: a priority matrix and a table of paths with required approvals and records.
Assign owners and handoffs to Safeguard 7.7 work
Map each tier and path to a responsible team and a handoff point. Document who receives a finding, who schedules the change, who verifies the fix and who closes the record. This is where the process feeds Safeguard 7.7, so the handoffs must be explicit for operating system patches, application updates and configuration fixes. Output: a RACI table covering detection, triage, fix, mitigation, acceptance and verification, reviewed by each team lead before publication.
Schedule and record the monthly review
Set a recurring calendar entry for the monthly review and define its agenda: new findings by tier, overdue items, open risk acceptances nearing expiry, and changes to asset inventory or exposure. Record each review with attendees, decisions and any document revisions. The assessment specification scores the process as failing if it was last reviewed more than 30 days ago, so the calendar entry and the minutes are the evidence an assessor will request. Output: a calendar entry and a dated review log.
Connect the process to the tools that produce findings
Identify the scanners and sources whose findings the process governs, such as the internal and external vulnerability scanners and the patch tooling. Record which tool feeds which asset group and how findings are consolidated, for example in a vulnerability management platform that deduplicates results. Confirm each tool's import and export options with its documentation before you rely on them. Output: a tool configuration record listing sources, owners, import method and the tier each source feeds, kept under change control.

Why the monthly review matters more than the first draft

Most remediation processes fail after approval, not during drafting. The document is signed, the review date passes without anyone noticing, and the strategy slowly stops matching reality. Safeguard 7.2 asks for a risk-based strategy that is reviewed at least monthly, and the assessment specification treats a review older than 30 days as a failure, so a lapsed review date is a measurable gap rather than a paperwork nuisance. Assign one named reviewer, put the review on a recurring calendar entry owned by a person rather than a team alias, and name a backup so the review still happens during leave.

Each review should test the strategy against what has changed since the last one. Check whether the severity thresholds still reflect how the business ranks risk, whether every asset class in the current inventory has a named owner, whether accepted risks have passed their expiry dates, and whether new exposure types such as newly internet-facing services, new cloud accounts or newly adopted software have a rule that says how quickly they must be fixed. Also confirm that the scanning and tracking tools still cover the assets in scope. Confirm with your own environment which of these items your inventory tooling can export on a schedule, because a review that depends on a stale asset list produces a stale strategy.

Record each review so the last-reviewed date can be proven to an assessor. A short dated record that lists the reviewer, the changes made, the accepted risks reviewed and the approver is sufficient for most evidence requests. Keep the prior versions of the document in version control so you can show what changed and when. This matters beyond the review itself, because Safeguard 7.7 applies this strategy to every detected vulnerability. If the strategy is out of date, every ticket that follows inherits the wrong priority, so a missed review is not a single lapse but a flaw carried into each remediation decision.

Evidence that passes a remediation process review

An assessor testing Safeguard 7.2 looks for a written process that exists, is current, and is actually used. The cards below cover the documents that prove the process was approved and reviewed, the decisions it records, and the tracker entries that show it operating. Each artifact needs an owner who keeps it current between audits.

Approved remediation process document

This is the written remediation process itself, setting out the risk-based strategy for fixing vulnerabilities. Assessors check that it exists, names its approver, and carries a version history showing when it changed. Keep one controlled copy in your policy repository and record each revision with the approver's name. The policy or security governance owner should maintain it, and the platform team should confirm that the scanning and ticketing steps described still match the tools in use.

Risk-based priority matrix

The matrix shows how a finding's severity, exposure, asset criticality and exploit status translate into a remediation deadline. It is the part of the process that makes the strategy risk-based rather than a fixed list of dates. Check that every rating input can be traced to a source, such as an asset inventory entry or a vulnerability feed. The vulnerability management lead should own the matrix and revisit it when asset classes or threat conditions change.

Review log with dates and reviewers

A dated log shows that the remediation process was reviewed at least monthly, with the reviewer's name, the changes made and any approvals. Assessors compare the most recent review date against the 30-day failure threshold in the assessment specification, so gaps are visible immediately. Set a recurring calendar entry and keep the log in the same repository as the process document. The process owner records each review, and a second person should spot-check that entries are complete.

Exception and risk acceptance register

When a vulnerability cannot be fixed within the defined timeline, the exception register records the reason, the compensating controls, the approving manager and the expiry date. Assessors look for exceptions that were approved by someone with authority over the risk, not by the system owner alone. Review open exceptions at each monthly review and close any that have passed their expiry. Risk owners in the business should approve entries, and the security team should maintain the register.

Ownership and RACI records

A RACI or ownership table names who is responsible, accountable, consulted and informed for each step: triage, prioritization, patching, verification and exception approval. Assessors use it to confirm that the process has a named accountable owner and that the people doing the work know their role. Confirm the table matches the actual staff and teams, since reorganizations are a common source of stale entries. The CISO or security governance lead should approve it, and HR or team managers should update it when roles change.

Tickets showing the process in use

Tracker records show the remediation process applied to real findings: a vulnerability is triaged against the matrix, assigned an owner, given a deadline, and closed with verification or an approved exception. Pull a range of records across severities and teams to show the process is followed, not just documented. Scanning and ticketing tools can export these records, and a tool such as DefectDojo can consolidate findings from several scanners into one tracker. The vulnerability management team should own the tracker hygiene, including consistent labels and closure reasons.

What meeting Safeguard 7.2 costs in money and effort

This table compares each cost component of keeping a remediation process in place, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Read it as a checklist for requesting quotes, since no figures are supplied here and actual amounts depend on your scope, tooling and environment. The main takeaway is that the largest recurring cost is governance time for the monthly review, so keeping the process short and tied to real tracking data usually matters more than the choice of tool.

Cost component	One-time or recurring	What drives it	How to keep it down
Policy and strategy drafting	One-time, plus revisions	Number of asset types, risk criteria, and how many business owners must agree on remediation timelines	Reuse a short template, write risk tiers once, and limit revisions to changes in scope or tooling
Governance time for the monthly review	Recurring	Attendees, size of the vulnerability backlog, and whether exceptions must be approved in the meeting	Pre-read a dashboard, cap the agenda to new critical findings and overdue exceptions, and delegate routine items
Tracking and deduplication tooling	Recurring (licenses or hosting)	Commercial licensing scale, number of scanners feeding the tracker, and user count	Open-source options such as DefectDojo remove license spend but still need hosting, upgrades and administration effort
Integration of scanners with the tracker	One-time, plus updates when tools change	Number and type of scanner report formats, and whether imports run through the UI or API	Confirm supported formats before buying or building, and automate imports on a schedule
Evidence upkeep	Recurring	Frequency of review records, retention rules, and how much evidence is collected by hand	Generate review records from the tracker and keep dated exports in one controlled location
External review or readiness assessment (optional)	One-time or periodic	Scope of the review, the organization's size, and whether an independent assessor is also engaged	Ask for a fixed-scope review limited to Safeguard 7.2 and its linked Safeguards, with deliverables listed in writing
Auditor sampling time	Periodic, per assessment cycle	Number of review periods sampled, quality of records, and gaps in dated minutes or approvals	Keep consistent records for every monthly review so samples can be pulled quickly

How DefectDojo and Greenbone produce remediation records

Open-source tools do not write or run a remediation process for you. They produce the records that show the process operates: which vulnerabilities were found, when, on which assets, who owns each fix and whether it closed. Safeguard 7.2 asks for a written, risk-based remediation strategy reviewed at least monthly, and the assessment specification fails the Safeguard when no process exists or the last review is more than 30 days old. The organization owns the strategy and the review log. The tools supply the findings that the strategy is applied to.

DefectDojo (BSD-3-Clause) is the place where findings from several sources can be tracked against that strategy. Its open source edition imports and reimports findings from more than 500 security tool report formats through the UI or API, and it includes a generic findings import for formats it does not list. It deduplicates findings using per-tool hashcode fields, so a finding that reappears in a later scan updates an existing record rather than creating a duplicate. Confirm the current list of supported formats and the exact hashcode behavior for each parser in the DefectDojo supported tools documentation before you commit to a design, because parsers change between releases.

Greenbone Community Edition (OpenVAS, AGPL-3.0-or-later) produces scan results for internal and external assets. Its gvmd service stores results in PostgreSQL, manages users and permissions, and schedules scan tasks, while analysts review results in the Greenbone Security Assistant web interface. Ask the implementation partner to confirm which scan cadence and report exports your remediation records will depend on, and check the current capabilities in the Greenbone Community documentation. Your legal team should review the AGPL-3.0-or-later terms before you distribute or modify the software, since those terms apply differently to internal use and to redistribution. Neither tool replaces the named owner, the monthly review record or the decision on which risks are accepted.

Who owns the process, who builds the records, and who tests them

Your organization owns the remediation process itself, the risk-based strategy inside it, and every decision about which vulnerabilities are fixed, when, and by whom. Safeguard 7.2 is a Govern and Documentation item, so the written process must reflect how your business actually weighs risk, not a template copied from elsewhere. Your team also runs the monthly review that the assessment specification checks, because a process last reviewed more than 30 days ago fails the test.

Strategy and priorities: Decide the risk criteria that set remediation timing, such as asset criticality, exposure and data sensitivity, and approve them through your normal governance route.
Risk acceptance: Record any vulnerability you choose not to fix, with a named approver, an expiry date and a compensating control. Partners can prepare the template but cannot make this decision.
Monthly review: Hold and minute the review, update the document, and keep the version history that proves the cadence.
Asset and owner mapping: Name the accountable owner for each system so findings reach someone who can act on them.

Before an assessment, confirm that the approved process has a dated review record from within the last 30 days and that every accepted risk has a current approver.

Questions buyers ask about the remediation process requirement

How much effort does a first remediation process take to write?

The effort depends mostly on how many teams touch vulnerability fixes and how much of your current practice is undocumented. A first version usually needs agreement on who triages findings, how severity and business risk are judged, which fixes can wait, and which fixes trigger an emergency change. Effort rises when ownership is split across infrastructure, application and cloud teams, and when no tickets or scan records exist to show how fixes are handled today. Ask any partner for a written scope listing the workshops, drafts and approval steps before work starts, since a fixed-scope quote follows from that list.

Can our team write the remediation process alone using CIS materials?

Yes, in most organizations, the CIS Controls are free for any organization to use to improve its own cybersecurity, and the Safeguard describes the outcome without prescribing a document format. Your team can write a risk-based strategy, define review cadence and record approvals without outside help. Teams that lack a vulnerability program or have no risk criteria often find the hardest part is agreeing on those criteria, not the wording. Check the license terms before reusing CIS text in a commercial document, because commercial use requires CIS's prior approval.

What does the process need from internal owners and sign-off?

The process needs named owners for triage, remediation by asset group, exception approval and the monthly review. Security typically drafts the strategy, while infrastructure, application and business owners confirm the timelines they can meet. An executive or risk owner should approve the document and accept exceptions, because the process must reflect accepted business risk. Record each approval with a date and version so an assessor can see who agreed to the strategy and when.

How long does an audit-ready remediation process need to build a track record?

The Safeguard assessment fails when no remediation process exists or when it was last reviewed more than 30 days ago, so the process must be reviewed at least monthly and the review must be on record. An assessor will look for a history of reviews, not a single document date, so the record needs to show repeated reviews over time. The exact period an assessor expects before accepting that history depends on the assessment, so confirm the expectation with your auditor or certification body before you rely on a timeline. Start the review calendar and minutes early, even if the first draft is still in progress.

Can a partner write the remediation process but not approve it?

Yes, and this division is the normal model. A implementation partner can prepare the draft, facilitate workshops, map the process to your scanning and ticketing tools and set up the review records. Your organization owns the controls, so your leadership must approve the process, accept risk and perform the reviews. Independent auditors and certification bodies are the only parties that issue reports or certificates. Write this split into the statement of work so no one assumes the partner has approved the process.

Do open-source scanners and trackers provide the evidence for this Safeguard?

Open-source tools can supply supporting evidence, but they do not replace the written process or its review record. Greenbone Community Edition schedules scans and stores results, and DefectDojo imports findings from many tool formats and deduplicates them, so both can show how vulnerabilities move from detection to tracked remediation. An assessor will still expect the documented strategy, the monthly review record and proof the strategy is applied to detected vulnerabilities. Confirm with your assessor which artifacts they accept, and check each tool's feature set in your own environment before you design the workflow around it.

Which Safeguard relies on this process for its daily work?

Safeguard 7.7 applies this process to detected vulnerabilities, so the remediation strategy becomes the rulebook for every fix. In practice, the review record shows whether the rules still match your risk appetite and tooling. Keep the process short enough that engineers will follow it, and make sure exceptions have an owner, an expiry and an approver. Engineers should be able to see the triage rules in the same tracker they use for fixes.

How DeployOpen prepares remediation process evidence

DeployOpen helps organizations prepare the written remediation process that Safeguard 7.2 asks for, along with the review records and tooling that show it is followed. The organization owns the process and its decisions, and an independent assessor is the party that tests and reports on it.

How we scope

Agree in writing which teams, asset classes and vulnerability sources the remediation process must cover.
Confirm who owns risk-based prioritization and who approves remediation timelines and exceptions.
Define the monthly review cadence and the records that prove each review took place.

How we build

Draft the remediation strategy with the organization so severity, exposure and business impact drive priority.
Configure self-hosted tooling so findings from scanners flow into one place for tracking against the process.
Test that the review date is recorded and that overdue reviews are flagged before an assessor asks.

How we hand over

Deliver the written remediation process, approval record and monthly review log in formats the organization keeps.
Document how the tooling produces the findings, status history and review evidence an assessor will sample.
Walk the internal owners through the process so they can run each monthly review without outside help.

How we support

Offer ongoing support and upgrades for the platforms under a retainer, if the organization wants continued help.
Update the remediation strategy when scope, asset inventory or risk appetite changes, with changes recorded.
Confirm with the organization and its auditor which evidence formats and sampling periods they will accept.

Safeguard 7.2 Establish and maintain a remediation process