CIS Safeguard 7.1: vulnerability management process

What Safeguard 7.1 requires and why the written process comes first

Safeguard 7.1 asks for a written process for managing vulnerabilities across enterprise assets, and that process must be reviewed at least once a year or after significant enterprise changes. If you have been asked to show CIS Control 7 coverage, this is the first document an assessor will look for, and it is the one that everything else in Control 7 depends on. Without it, there is no agreed answer to who decides what gets scanned, how often, who owns each finding, and when a problem goes to a manager or the business. The risk this Safeguard addresses is a familiar one. An organization may run scanners and apply patches, yet no one can say which assets are in scope, which team triages the results, how quickly a critical finding must move, or who accepts a risk that cannot be fixed on time. Scanning without a defined owner produces reports that sit unread. Patching without a cadence produces gaps that nobody notices until an incident exposes them. A written process turns these activities into one chain: scope, discovery, scanning, prioritization, remediation and escalation, each with a named role. It is the Govern Safeguard that opens Control 7 because the later Safeguards, from remediation (7.2 and 7.7) through patching and scanning (7.3 to 7.6), need a process to reference.

Writing the document is usually the easy part. Keeping it current is harder, because the scanners, asset inventory, cloud accounts and ownership structure change while the document stays still. The assessment specification treats a process that has not been updated in more than 12 months as failing, so the review cycle matters as much as the first draft. Before you start, confirm with your assessor or CIS guidance which evidence of review they will accept, such as a version history, an approval record or a change ticket tied to a significant change. Then decide which system holds the document, who signs off on updates, and which events trigger an early review, such as a new cloud region or a change in scanning tools.

Which assets, teams and third parties the vulnerability management process must cover

Safeguard 7.1 asks for a process across enterprise assets, so the scope is set by your own asset inventory from Controls 1 and 2, not by the systems your scanner already sees. The cards below cover the scope decisions that most change the effort, and each one is something an assessor will check against your inventory.

Endpoints and user devices

Laptops, desktops and mobile devices are often the largest group of enterprise assets, and they are easy to leave out when a process is written around data center servers. Check that the process names endpoints explicitly and that it covers devices that are off the network for long periods, since they still need patches and scans when they return. Confirm the endpoint count against the detailed asset inventory before you agree on a scan and patch cadence.

Cloud accounts and workloads

Virtual machines, containers and managed services in each cloud account are enterprise assets in their own right, and they are often provisioned by teams outside central IT. Confirm which accounts, subscriptions and projects are in scope, and who can create new ones. A process that covers on-premises servers but excludes cloud accounts will not match what Safeguard 7.1 describes.

Network devices and software inventory

Firewalls, switches, routers and the software running on them carry vulnerabilities that scanners and patch tools often miss. Use the software inventory from Control 2 to decide which applications, libraries and firmware fall under the process. Ask whether each network device has a named owner who receives its findings.

Externally exposed services

Internet-facing hosts, load balancers, VPN gateways and public APIs carry the highest exposure and have the shortest exploit windows. Safeguard 7.1 covers them within the same process, but the external scan cadence in Safeguard 7.6 is tighter than the internal one. List every public address and hostname in the scope, and confirm that new public services trigger an update to that list.

Named owners for each asset group

Scanning, patching and remediation are performed by different teams, often in different reporting lines. Record an owner for each asset group and state who approves a risk acceptance when a fix cannot be applied. Without named owners, findings sit in a queue and the process cannot show that it operates as written.

Third parties that touch vulnerable assets

A managed service provider, a hosted platform or a contractor with administrative access can change or expose assets that sit inside your scope. Decide whether their systems are covered by your process or by their own, and write that split into the contract. Confirm how they report findings to you and how quickly they apply fixes to systems they operate.

How an assessor tests the process against the 12-month rule

This table walks through the checks an assessor makes against Safeguard 7.1, from confirming the written process exists to tracing it into remediation. The CIS assessment specification scores the Safeguard on two measures, existence and months since the last update, so the evidence column shows what to produce for each step. Read the common findings column first to see where organizations usually fail.

Test step	Test approach and evidence requested	Common findings
Confirm the process exists	Ask for the written vulnerability management process as a controlled document with a title, owner and approval record. The CIS assessment specification scores a missing process as failing.	Scanning happens, but no document describes it. Tool configurations are offered as the process.
Check coverage of enterprise assets	Compare the process scope statement against the asset inventory from Controls 1 and 2. Confirm devices, software, cloud workloads and externally exposed assets are named or covered by reference.	Scope lists only servers or only the data center. Cloud accounts, endpoints and SaaS are absent.
Check the date of the last update	Review the document version history and approval dates. The assessment specification measures the months since the last update and fails the Safeguard when that gap is more than 12 months.	Last revision carries an old date, or the version history was lost during a document system migration.
Check for a review after enterprise change	Ask for change records from significant enterprise changes such as acquisitions, new cloud regions or new platforms, and the matching review entries in the document history.	The annual review happened, but no review followed a major change. Changes are recorded in tickets that never reach the process owner.
Check the link to the remediation process	Confirm the vulnerability process points to the remediation process required by Safeguard 7.2 and that remediation timelines and owners are defined or referenced.	The process ends at detection. Findings have no defined path to a remediation owner or deadline.
Check the process is in use	Sample recent scan results and tickets to confirm the written steps match what staff actually do. Ask for the owner's name and the approval of the current version.	Staff follow an undocumented routine that differs from the written steps, or the named owner has left the organization.
Confirm no prerequisite Safeguards	The assessment specification lists no prerequisite Safeguards for measuring 7.1, so the assessor tests this Safeguard on its own evidence. Confirm this with the current assessment specification before the test.	Teams assume a prerequisite must pass first and delay the test, or they assume Safeguard 7.1 depends on scan results that are not part of its measures.

Evidence that shows the vulnerability management process is current

Safeguard 7.1 is tested on two things: whether a process exists and whether it was updated within the last 12 months. The cards below are the artifacts that prove both, and each one needs a routine that keeps it current between assessments.

Approved process document

The written vulnerability management process itself, with a version number and the date it was approved. Check that it names the enterprise assets in scope, the roles that scan, triage and remediate, and the cadence for each activity. Store it in a controlled location where the version in force is unambiguous. Between audits, set a calendar-driven review task so the owner confirms the document still matches how scanning actually runs.

Revision history

A dated record of every change to the process, showing what changed, who made the change and why. The assessment reads the months since the last update, so this history is the fastest way to prove currency. If the document lives in a wiki or document platform with version control, export or screenshot the revision log at assessment time. A change that edits only a typo still counts as an update, so keep those entries honest.

Annual review record

A signed or logged record that the process was reviewed, with the reviewer, the date and the outcome, even when the outcome is no change. Safeguard 7.1 calls for review once a year and after significant enterprise changes, so the record should show both triggers. Schedule the annual review as a recurring task with a named owner, and require a written outcome so an empty review cannot pass as a completed one.

Change-triggered review record

Evidence that a significant change, such as a new cloud account, a merger, a new scanning tool or a change in internet exposure, prompted a review of the process. Add a question to the change management workflow asking whether the change affects vulnerability management scope or cadence. Keep the ticket or change record that links the change to the review, so the assessor can trace the trigger without relying on memory.

Scope statement tied to the asset inventory

A statement that defines which enterprise assets the process covers and points to the asset inventory that lists them. This matters because Safeguard 7.1 applies to all enterprise assets, so a scope that names only servers leaves gaps an assessor will find. Confirm that new assets added to the inventory fall within scope automatically or through a documented step. Review the scope statement with each annual review and whenever the inventory changes materially.

Sign-off from the accountable owner

An approval record from the person accountable for vulnerability management, usually a named executive or security leader, showing that they accepted the process and its scope. Without it, the process is a working draft that nobody has committed to. Record the approval date next to the version number on the process document. Each annual or triggered review should produce a new sign-off, so the approval history matches the revision history.

Writing and approving the process, step by step

This sequence turns Safeguard 7.1 into a written, owned and approved process that connects scanning, remediation and review, so an assessor can see a current document and a record of who accepted it.

Confirm the asset scope from the inventory
Start by reconciling the process scope against your asset inventory from Controls 1 and 2, so the process names the device, software and cloud populations it covers. The people doing this are the asset owner and the security lead, working from the current inventory extract. The output is a scope statement that lists asset classes, environments and any exclusions with a stated reason. You know the step is done when every exclusion has a named owner and a justification that a reviewer could challenge.
Define scanning sources and cadence
Describe which scanning sources feed the process and how often each runs. Internal scanning follows the quarterly or more frequent cadence in Safeguard 7.5, and externally exposed assets follow the monthly or more frequent cadence in Safeguard 7.6. Name the tools in use, such as a scanner, cloud posture tooling or software composition analysis, and confirm each one reaches the scope from the previous step. The output is a sources table with tool, asset population and cadence. The step is complete when no in-scope asset class lacks a source.
Define triage and handoff to remediation
Write the rules for how raw findings are deduplicated, validated, prioritized and passed to the remediation process in Safeguard 7.2. Specify who accepts a finding, how false positives are recorded and what information a remediation ticket must carry, such as affected asset, severity basis and due action. A findings platform can help keep this consistent, but the decision rules belong to your organization. The output is a triage and handoff section with a worked example labeled as illustrative. The step is verified when a sample finding can be traced from detection to a remediation record.
Assign owners and escalation paths
Name an accountable owner for the process as a whole, and a responsible owner for each scanning source, triage queue and remediation team. Define the escalation path for findings that are overdue, disputed or affect critical services, including who is informed and who decides. The output is an owner register listing role, named person, backup and escalation contact. The step is complete when every role in the process has a named individual and a backup, and the register has been confirmed by each person listed.
Document the review trigger and annual cycle
Record the review obligations the Safeguard sets: a review at least once a year and after significant enterprise changes. Define what counts as a significant change in your environment, such as a new cloud region, a merger or a change in internet-facing services, and assign who decides that a trigger has occurred. Add a revision history block to the document so each update is dated and attributed. The output is a review section and a change log. The step is verified when the document shows a last-updated date that a reviewer can compare against the review schedule.
Obtain approval and record it
Send the completed draft to the executive or governance body that the organization designates to approve security processes, and record the decision. The approval record should show the document version, the approver's name and role, the date and any conditions attached. Store the signed or recorded approval with the document in a controlled repository so access and versions can be audited. The output is the approved document and its approval record. You know the step is done when an assessor could follow the link from the Safeguard to the current, approved version without asking for the draft.

What the written process costs in effort, tooling and review

This table compares each cost component of keeping a vulnerability management process current, who carries it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a written quote, since no price or duration is stated here because none has been supplied. The main takeaway is that the process itself is inexpensive to write, while the recurring cost sits in keeping its review dates and evidence current.

Cost component	One-time or recurring, and who pays	What drives it up	What keeps it down
Drafting the process	One-time. Internal security and engineering staff, or the implementation partner if scoped in writing.	Number of asset classes covered, number of business units with their own scanning, and multiple scanning tools to describe.	Reuse of an existing vulnerability or patch policy and a single scope statement across enterprise assets.
Maintaining the process document	Recurring. Internal security staff, at least at the annual review and after significant enterprise changes.	Frequent changes to scanners, ticketing or asset scope, which force edits to the document.	Describing roles and tools by function rather than product name, so routine tool changes do not reopen the text.
Governance approval	Recurring at each review. Management or risk committee time, plus any change board signoff.	Multiple approval layers, approvers outside the security team, and regulatory overlap that requires legal or compliance review.	A named owner with delegated approval authority and a fixed review calendar agreed in advance.
Tracking tools for the document and findings	Recurring. Licenses for a wiki or document platform, or hosting and admin time for a self-hosted one. Self-hosted open source removes license spend but not staff time to administer it.	Separate systems for the process text, the findings register and the review log, and integrations that need custom maintenance.	One version-controlled location for the process text, with the review date and approval recorded on the same page.
Evidence upkeep for review cycles	Recurring. Internal staff, who record each review date, change event and approval.	Manual evidence assembly, scattered approvals, and many business units each keeping their own records.	A review log with dated entries, linked to the document history so each update can be traced to who made it and when.
External review, if purchased	Optional and recurring when used. Paid to an independent reviewer selected in writing; this is a review, not an assessment or certification.	Breadth of scope, number of frameworks mapped to the same text, and the depth of review requested.	Limiting the review to the written process and its update history, with the scope and deliverables agreed before work starts.
Auditor sampling time	Recurring at each assessment cycle. Internal staff time to provide samples, paid to the auditor for testing.	Frameworks that test this Safeguard alongside others, and gaps in the revision history that prompt extra sampling.	Keeping the revision history complete and easy to export, so samples can be produced quickly.

Open-source tools that hold the process and its findings

None of the tools below approves or issues the vulnerability management process; the accountable owner does that. Together they hold the written process, the scanning that the process governs, the findings it generates, and the approval history that shows the process stayed current.

DefectDojo for tracked findings

DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and offers a generic findings import. It deduplicates findings using per-tool hashcode fields. For Safeguard 7.1, this is where the process meets its records: check that each scanner you run has a supported import path, that deduplication behaves as expected for your tools, and that the owner can show who triaged each finding. Confirm current format support in your own environment. Licensed under BSD-3-Clause.

Greenbone Community Edition for scan evidence

Greenbone Community Edition, built on OpenVAS, uses gvmd as a vulnerability management service that stores results in PostgreSQL, manages users and permissions, and schedules scan tasks. Users run scans and review results in the Greenbone Security Assistant web interface. The process governs these scans, so the stored results and task schedules are the evidence that the process runs in practice. Confirm the scan coverage and schedule features you need, since Safeguard 7.1 itself does not set scan frequency. Licensed under AGPL-3.0-or-later, which carries source obligations if you modify and distribute it.

XWiki for revision history

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For Safeguard 7.1, the written process is only as credible as its history: an assessor will look for the last review date and what changed at that review. Check that your reviewers are recorded on each change and that your retention and backup settings keep the history intact. Licensed under LGPL-2.1-or-later.

BookStack for controlled approval

BookStack assigns user abilities from the roles each user holds, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets you separate who may edit the vulnerability management process from who may approve it. Map each role to a named responsibility, and test that an editor cannot publish changes to the approved version without review. Confirm how approval workflows are handled in your version, since the tool controls access, not sign-off. Licensed under MIT.

Your team, an implementation partner and the auditor for Safeguard 7.1

Your organization owns Safeguard 7.1. The written vulnerability management process must reflect how your enterprise actually finds, prioritizes and tracks vulnerabilities across its assets, and it must be approved by someone with the authority to commit resources to it. Your team also decides what is in scope, since an out-of-date asset list makes an otherwise sound process incomplete.

Owning the process: Name an accountable owner, usually in security or IT risk, who answers for the document and its outcomes.
Approving the process: Record formal approval by management, with the approver's name, role and date.
Running the annual review: Review the process at least once a year and after significant enterprise changes such as a merger, a cloud migration or a new scanning tool.
Keeping scope accurate: Confirm that the process covers enterprise assets, including cloud, remote and third-party hosted systems, and update the asset inventory it relies on.
Keeping the review record: Store each review with the reviewer, the changes made and the approval, so the last-updated date can be shown to an assessor.

Before relying on the process, confirm that your named owner can state, without notes, where the document lives and when it was last approved.

Where organizations fall short on the 12-month test

Safeguard 7.1 is assessed on two things: whether a vulnerability management process exists, and whether it was updated within the last 12 months. Most shortfalls come from processes that are out of date, unowned, narrow in scope, disconnected from remediation, or reviewed without a record, and each has a concrete fix with evidence an assessor can check.

Process approved more than 12 months ago

A process document may exist but carry an approval date older than a year, which the assessment specification scores as failing. Set a review calendar with a named reviewer, and schedule the review ahead of the 12-month mark rather than after it. Close the gap by approving a current version, recording the date in the document header, and keeping the prior approval in version history. Check the last-updated date against the calendar before any assessor asks for it.

No named owner or approval record

A process with no accountable owner or sign-off cannot show who decided how vulnerabilities are handled. Assign a role, such as the head of security operations, as owner, and record approval by a named executive or governance body. The evidence is a document control block listing owner, approver, approval date and scope, plus the approval record itself, such as a signed change ticket or meeting minutes. Confirm that the approver has authority over the enterprise assets the process covers.

Scope limited to servers

Many processes describe server patching and scanning but say nothing about cloud workloads, container images, or endpoints. Safeguard 7.1 applies to enterprise assets generally, so the process should name each asset class in scope and state how each is discovered and scanned. Ask your asset inventory team to confirm that cloud accounts and laptops appear in the scope statement. Evidence includes a scope section mapped to the asset inventory from Control 1 and Control 2.

Process not linked to remediation

A vulnerability process that stops at detection leaves no path to fixing findings. Safeguard 7.2 requires a separate remediation process, and Safeguard 7.7 applies it to detected vulnerabilities, so the two documents should refer to each other. Add a cross-reference that names the remediation owner, the severity thresholds that trigger action, and the ticketing or tracking system. Evidence is a traceable chain from a scan finding to a remediation ticket and its closure record.

Paper review with no change trace

A review that is signed off without any visible change history makes it hard to prove the process was actually examined. Keep the process in a version-controlled wiki or document system so each edit records what changed, when and by whom. Compare the reviewed version against the prior one and retain the diff. The evidence an assessor will look for is the revision history showing substantive edits or a documented confirmation that no change was needed.

Questions buyers ask about Safeguard 7.1 cost, effort and outsourcing

How much effort does writing a vulnerability management process take?

The effort depends mostly on how many asset types the process must cover, how many teams already run scanning or patching, and whether any written material exists to build on. A small organization with one IT team and a single scanner can usually draft the document in a few working sessions. A larger enterprise with cloud accounts, data centers, endpoints and third-party hosted systems needs more time, because each asset class has its own owners, scan cadence and patch path, and the process must name how they connect. Writing is only part of the work. The process also needs agreement from the teams that will follow it, which often takes more rounds than the drafting itself. Ask any proposal to break the effort into drafting, stakeholder review, and approval as separate line items.

Can our own team write the vulnerability management process without outside help?

Yes, in most organizations the internal team can write it, and Safeguard 7.1 does not require an external party. The organization owns the process and must be able to show it is in use. Outside help is useful when no one on the team has written a security procedure before, when several departments must agree on responsibilities, or when the existing scanning and patching practices are undocumented and need to be recorded first. An implementation partner can prepare drafts, map the process to the systems in your environment and gather the evidence that the process runs. It cannot issue an assessment result or certify the process. Any independent assessor will still test the document against what your teams actually do.

How long does the first version take to approve?

The approval time depends on how many reviewers must sign off, how quickly those reviewers respond, and whether the process must fit an existing change or risk governance structure. Typical paths include security leadership, IT operations, the owners of major systems, and sometimes legal or compliance. Each added approver adds a review cycle. The safest planning assumption is to ask your leadership how their approval calendar works and to confirm the review steps in writing before the work starts. A fixed-scope engagement should name the approval stages as deliverables so that the schedule reflects real governance, not only the drafting time.

What does the organization need to provide before the process can be written?

Three inputs make the process specific rather than generic. The first is an asset inventory covering the enterprise assets in scope, including devices, software, cloud resources and any externally exposed systems, because the process must state how each asset class is handled. The second is named owners for vulnerability intake, risk decisions, patching and scan operation, with a deputy for each role. The third is a change process that the vulnerability process can reference, so that significant enterprise changes trigger a review. If any of these is missing, the first task is usually to build it, which adds effort. Confirm each input with your owners before accepting a fixed scope.

Do open-source scanners and tools remove the need for a written process?

No. Tools such as Greenbone Community Edition or DefectDojo produce findings, store results and track their status, but they do not decide who owns a finding, how fast each severity is handled, which assets are in scope or when the process itself is reviewed. Those decisions are written in the process document, and an assessor will look for the document as well as the tool output. Tooling is valuable as evidence that the process runs. Use the tools to show scan records, deduplicated findings and remediation status, then point each record back to the clause of the process it follows. Confirm with any tool vendor which features are in your version before you design the workflow around them.

Is a yearly review enough, or does the process need a review after changes too?

Both are needed. Safeguard 7.1 calls for review at least once a year and also after significant enterprise changes, so the annual review is the minimum rather than the whole obligation. In the CIS assessment specification, the measure looks at when the process was last updated, and a last update more than 12 months ago fails. Build a trigger list into the process, such as new cloud regions, acquisitions, a change in scanning tools, or a new externally exposed service, and record each review with a date, reviewer and outcome. Keep the review record in your document system so the update history is visible to an assessor.

What should a written scope and quote for this work include?

Ask for a scope that lists the assets and business units the process covers, the named deliverables such as the process document, role descriptions, review schedule and evidence index, and the approval steps that the work must pass through. The quote should separate one-time work, such as drafting and stakeholder workshops, from recurring work, such as annual reviews and any ongoing support. It should state what the organization must provide, including the inventory and named owners, and what is excluded, such as scanner deployment or remediation work under other Safeguards. Ask how changes to scope are priced and approved. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen works on this

DeployOpen helps organizations write, deploy and evidence a vulnerability management process for Safeguard 7.1 on self-hosted open-source platforms inside the client's own infrastructure. The organization owns the process and its approval, and an independent assessor or auditor reviews it, since DeployOpen prepares systems and evidence but does not issue reports or certifications.

How we scope

Engagements are fixed-scope, with the written scope agreed before any work starts on the vulnerability management process.
The scope names which enterprise assets, tools and teams the written process covers, and who approves it.
The scope sets the annual review trigger and the process for reviews after significant enterprise changes.

How we build

We draft the process document structure so it covers scanning sources, triage ownership, and handoff to the remediation process in Safeguard 7.2.
We configure the chosen open-source tooling, such as Greenbone Community Edition and DefectDojo, to feed findings into the documented workflow.
We test that the workflow runs end to end and record the results so the process is demonstrably in operation.

How we hand over

You receive the process document in a version-controlled wiki, with a revision history showing when and by whom changes were made.
Handover includes a review calendar that shows the annual review date and the last update date that the assessment checks.
We document the evidence location for each step so your team or an independent assessor can find it without help.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial fixed-scope work ends.
Retainer support can keep the review cycle current, so the last update date stays inside the 12-month window the assessment uses.
Ask your assessor or auditor to confirm the evidence format they expect before we finalize the handover package.