Safeguard 16.6 severity ratings: requirements and evidence

What Safeguard 16.6 asks for and why ratings decide fix order

An application team with a long list of open findings and no agreed order for fixing them is the situation Safeguard 16.6 is meant to end. The Safeguard asks for a severity rating system and process for application vulnerabilities that decides which findings get fixed first and sets a minimum level of security acceptability before code or an application is released. In plain terms, the organization writes down how each finding is scored (for example, by impact and exploitability), what each score means for timing, and who may accept a risk instead of fixing it. The CIS Controls Assessment Specification scores an enterprise as failing this Safeguard if no such system and process exists, and CIS asks that it be reviewed and updated annually. Safeguard 16.6 is an IG2 Safeguard, so it applies to IG2 and IG3 enterprises but not to IG1 organizations, which the Implementation Groups treat as essential hygiene.

The rating system depends on the intake process in Safeguard 16.2, which is a listed prerequisite for measuring 16.6. Intake produces the findings (from reports, scanners, penetration tests and developers), and the rating turns them into a queue. Without a defined intake, the team cannot tell which findings are open, how long they have been open, or whether they were ever triaged, so the scale has nothing reliable to score. Before drafting the scale, confirm that your intake process already records each finding with a source, an affected application and a status.

The hard parts are usually organizational rather than technical. Product teams often use different scales, so a "high" in one team means something else in another, and agreeing one scale across teams requires a named owner with authority to settle disputes. The second difficulty is enforcement at release. A rating that does not block a release when a threshold is breached is a guideline, not a minimum bar, and the assessor will look for evidence that the threshold was applied to real releases, including documented exceptions and who approved them. Ask your team to show the last several releases with their open findings and the decision recorded for each.

Which applications, teams and third parties fall under the rating process

Safeguard 16.6 applies to the application vulnerabilities an enterprise is responsible for, so the first decision is which software sits inside that boundary. The cards below cover the scoping choices that change the work, from in-house code to acquired products and the third-party components that feed findings into the process.

In-house applications

Applications your own teams write are the core of the rating process, because your organization sets their fix order and their minimum bar for release. Scope every internal application that handles sensitive data or business transactions, including internal tools and scripts that run on production systems. Check that each one has an owner who can accept a severity rating and commit to a fix window. Effort rises with the number of codebases and release pipelines that must share one rating scale.

Hosted and SaaS applications

Software your organization runs on infrastructure it controls, or consumes as a hosted service, may still carry vulnerabilities you must rate and prioritize. Confirm which findings your team can fix, such as configuration and integration issues, and which must go to the provider. Record the provider's disclosure channel and expected response in the rating process so findings do not stall. The effort here depends on how much of the stack your contracts let you test or patch.

Acquired commercial software

Packaged products you buy or license need the same rating treatment as internal code, but the fix path usually runs through a vendor patch. Inventory each product and its support status, then decide how a vendor advisory maps to your severity scale and your release gate. Ask vendors how they rate their own vulnerabilities and whether their ratings match yours. Expect extra coordination effort when a vendor is slow to patch and you must choose between waiting and compensating controls.

Third-party components and libraries

Open-source libraries and frameworks inside your applications create findings that appear in scanners and dependency reports, often without a named owner. Tie each component back to the application that uses it, so a library flaw receives the same severity rating and fix order as a flaw in your own code. This link to the component inventory described under Safeguard 16.4 is what makes the rating process traceable. Effort grows quickly with transitive dependencies, so start with components that reach production.

Teams and product owners

The rating process only works when every team that ships software knows it applies to them and who decides severity. Name a responsible owner for each application, and document which teams can propose a rating change and which role approves it. Include contractors and outsourced development teams in the same scope, because their code reaches production under your release gate. Confirm that each owner receives the rating scale and the annual review schedule that Safeguard 16.6 expects.

IG2 and IG3 enterprise scope

Safeguard 16.6 sits in Implementation Group 2, so IG2 and IG3 enterprises must apply it, while IG1 enterprises do not. Under the CIS Controls Assessment Specification, the process cannot be measured without the prerequisite intake process in Safeguard 16.2, so scope both together. Check whether your Control 16 scope already covers the applications you want rated, because a rating process that skips a development team leaves a gap an assessor will find. Confirm the expected scope with your assessor or CIS guidance before you size the work.

How to build the severity rating process in sequence

This sequence turns Safeguard 16.6 into a working process: a rating scale, fix-order rules, a release bar, named owners and an annual review, each with a written output the assessor can inspect. It starts from the intake process in Safeguard 16.2, because ratings only mean something when vulnerability reports are already being received and tracked.

Confirm the Safeguard 16.2 intake process exists
Before writing any rating rules, check that your organization already accepts software vulnerability reports, routes them to a named team and tracks them to remediation. The CIS Controls Assessment Specification lists Safeguard 16.2 as a prerequisite for measuring 16.6, so an assessor will look at it first. Owners are typically the application security lead and the team that receives reports. The output is confirmation that intake and tracking records exist, or a gap list to close before continuing. Confirm the exact prerequisite wording with the assessment specification for your version.
Define the rating scale and its criteria
Write a severity scale with a defined number of levels and a written criterion for each level, covering factors such as exploitability, data exposed, authentication required and affected business functions. Agree the scale with security, development and the business owners of critical applications so ratings are applied the same way across teams. The output is a versioned, approved rating document that names each level and the criteria that place a finding in it. Ask any external scoring method you adopt, such as a published base score, to be recorded alongside your own adjustments so the basis for each rating stays traceable.
Set fix-order rules for each rating
Translate each severity level into a rule for fix order, such as which levels must be addressed first, which can be scheduled into normal development work, and which may be accepted with documented justification. Keep the rules short enough that engineering leads can apply them without a meeting. The output is a fix-order table that is linked from the vulnerability tracking system, so every new finding receives its rating and its expected handling at intake. Confirm the target handling windows with your own risk owners, since this document should set them explicitly rather than inherit them from a template.
Set the release bar that allows or blocks a build
Define the minimum security acceptability for releasing code or applications as a rule tied to ratings, for example which open findings of which levels stop a release from proceeding to production. Specify who can approve an exception and what evidence must accompany it. Implement the rule in the pipeline or in a release checklist, so the decision is recorded rather than informal. The output is a written release gate rule and a sample pipeline or checklist record showing a build that was blocked or allowed under it. Test the gate against a few recent builds to confirm it behaves as the written rule says.
Assign owners and a formal exception process
Name an owner for the rating scale, for each application or product team that applies it, and for approving exceptions. Create an exception form that records the finding, its rating, the business reason, the compensating measures, the approver and an expiry date that the exception owner has agreed. The output is a responsibility matrix and an exception register that can be filtered by application and by approver. Ask the auditor which records they will sample, and make sure the register can produce them quickly.
Record ratings and fix decisions in tooling
Apply the scale to real findings in your tracking system so the rating, the fix order and the release decision are recorded together. Open-source tools such as DefectDojo can import findings from many scanners and deduplicate them, which helps keep one rating per underlying issue, and Greenbone Community Edition can supply scan results for infrastructure-facing applications. Check that each finding carries its rating, owner and status. The output is a sample of rated findings with their fix and release decisions, which serves as direct evidence that the process operates.
Schedule the annual review and record it
CIS asks that the Safeguard 16.6 system and process be reviewed and updated annually. Put that review on a calendar owned by a named person, and review the scale, fix-order rules, release bar, exception register and recent release decisions against changes in threats, applications and the vulnerability intake data. The output is a dated review record with the attendees, the changes approved and the new version number of the rating document. Keep prior versions so an assessor can see that the process was reviewed, not simply written once.

How an assessor tests the severity rating system

This table walks through the checks an assessor applies to Safeguard 16.6 under the CIS Controls Assessment Specification, from confirming a rating system exists to confirming the annual review. Read it as a sequence: a missing scale fails the test at the first step, and weak evidence at later steps usually produces a partial finding.

Assessment step	What the assessor looks for	Typical finding when it fails
1. Confirm the system exists	A documented severity rating scale for application vulnerabilities, with defined levels and the criteria used to assign each level	No rating system and process at all, which the Assessment Specification scores as failing
2. Check the prerequisite	A vulnerability intake process under Safeguard 16.2 that feeds findings into the rating system	Ratings exist, but findings arrive from ad hoc sources with no intake path to rate them
3. Check fix order	Evidence that the rating determines remediation priority and target timing for each level	Scale names levels such as critical and high, but backlog order is set by whoever shouts loudest
4. Check the release bar	A stated minimum security acceptability for releasing code or applications, tied to severity levels	No rule that blocks a release with open high-severity findings, or the bar exists only as an informal habit
5. Sample real findings	Recent application vulnerabilities with the severity assigned, the date rated and the remediation outcome	Scale exists only in a document nobody uses, so tickets carry no rating or ratings are inconsistent between teams
6. Confirm the annual review	Records showing the scale and process were reviewed and updated within the last year	Document dated to its first release with no review record, or a review that changed nothing and was not recorded
7. Match tooling to the scale	Scanner or tracker severity fields mapped to the internal scale, so output is comparable	Tool severities imported unchanged, producing duplicate or conflicting priorities across tools

Which evidence shows the rating process works and stays current

An assessor testing Safeguard 16.6 looks for a written rating system, the rules that order fixes and a release bar, and proof that the process was followed on real findings. The cards below cover each artifact and how to keep it current between audits, so the evidence is not assembled only when an assessment is scheduled.

Written severity rating standard

This is the document that defines how each application vulnerability is rated, such as the scale used, the criteria for each level and who assigns the rating. It is the base of the Safeguard 16.6 assessment, because the Assessment Specification gives a failing score when no severity rating system and process exists. Keep it under version control, and log every change with its approver and date so the current version and its history are both visible. Check that the rating terms match those used in your ticketing and scanner tools.

Fix-order rules

These rules translate each rating into a remediation window and a queue position, so developers know which findings come first. Record the rules as configuration or a policy table, not only as prose, so a sample of tickets can be traced back to them. Review the rules whenever ratings change, and confirm that the scanner or tracker applies the same ordering the document describes.

Release criteria

The release criteria state the minimum security bar for shipping code or an application, such as which open findings above a given rating block a release and who may approve an exception. Enforce them in the pipeline where possible, so a failed gate leaves a record. Keep the gate results per build, because an assessor will ask whether releases were stopped when the bar was not met.

Sample of rated findings

Assessors usually select a sample of application findings and check the rating, the date it was raised, the fix order applied and the decision taken. Keep each finding in a tracker with its rating history, timestamps and linked decision, which the DefectDojo import and deduplication workflow can help consolidate across tools. Export the sample set monthly so the evidence exists before an audit asks for it.

Exception approvals

Where a finding is accepted above the release bar, the exception must name the finding, the business reason, the compensating control, the approver and an expiry date. Store exceptions in the same system as the findings so they cannot be closed silently. Review open exceptions at a set interval, and confirm that none have passed their expiry without a new decision.

Annual review record

Safeguard 16.6 expects the rating system and process to be reviewed and updated annually. The record should show the review date, the people involved, the changes made and the reason for each change, such as a new scanner or a revised risk appetite. Schedule the review as a recurring task in your governance calendar, and keep the signed outcome with the standard so the review trail stays linked to the current version.

Using DefectDojo and Greenbone to apply severity ratings

Safeguard 16.6 asks for a severity rating system and process, and the tools below help apply it to the findings you already collect. Neither tool decides your rating scale, so the cards focus on where ratings, fix status and scan results end up and what an assessor can trace from them.

Centralizing findings in DefectDojo

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats, including in the open source edition, and offers a generic findings import for anything else. Using one place for findings lets your severity field and fix status stay consistent across tools. Confirm which report formats your scanners produce and whether they carry a severity value that maps cleanly to your scale.

Deduplicating with per-tool hashcodes

DefectDojo deduplicates findings using per-tool hashcode fields, so the same flaw reported by repeated scans is not counted as several open issues. This keeps the queue that drives fix order accurate. Check that deduplication settings match how your teams want recurring findings tracked, and document the rule so that an assessor can see why two records were merged or kept apart.

Greenbone scan results in PostgreSQL

Greenbone Community Edition (OpenVAS, AGPL-3.0-or-later) uses gvmd to store scan results in PostgreSQL and to schedule scan tasks, manage users and control permissions. Those stored results and task records are evidence that scanning happened on a defined schedule. Confirm the retention period for these results in your environment, since the tool does not set it for you.

Reviewing results in Greenbone Security Assistant

Users run scans and review results in the Greenbone Security Assistant web interface, which gives a per-user record of who ran which task and reviewed which findings. For Safeguard 16.6, this helps show that severity assignments are made by named people under defined permissions. Confirm that role assignments in gvmd match your documented approval roles for rating decisions.

Setting the rating scale yourself

Neither DefectDojo nor Greenbone defines your severity scale, your fix deadlines per rating or your minimum bar for releasing code. Those values belong in your written process, and the tools only record them. Before rollout, confirm how each tool's severity values, including the scanner's own scores, will be mapped to your scale, and record any overrides with a reason.

Mapping evidence to the annual review

The Safeguard 16.6 process is reviewed and updated annually, so keep the scale, mappings and permission settings under version control and dated. Export DefectDojo findings and Greenbone task history at the review point to show how the process was applied. Ask your auditor which exports they will accept as evidence before you build the routine.

What meeting Safeguard 16.6 costs in money and effort

This table breaks down the cost components of running a severity rating system and process for application vulnerabilities, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No fees or durations are given because none are supplied for this Safeguard, so use the last column to build a written quote from your own scope.

Cost component	One-time or recurring	Who is paid or who spends time	What drives it up or down
Tooling and licenses	Recurring if commercial; one-time setup	Vendor or open-source maintainers; internal platform team	Open-source tools such as DefectDojo (BSD-3-Clause) and Greenbone Community Edition (AGPL-3.0-or-later) can remove license spend, but check the AGPL-3.0-or-later copyleft terms with counsel before modifying and distributing them
Engineering time to define the scale and release gate	One-time, then revisited at each review	Internal engineering leads, product security, possibly an external implementation partner	Number of application teams, number of languages and platforms, and whether one scale covers in-house, hosted and acquired software
Security time to calibrate ratings	One-time, then ongoing as findings accumulate	Application security staff and senior developers	Volume of scanner and pen test findings, duplicate rates, and how many false positives are triaged before a rating is assigned
Tool integration and workflow setup	One-time, with recurring upkeep after tool upgrades	Platform engineers or an implementation partner	Number of report formats imported, whether ratings sync to the ticketing system, and whether deduplication rules need tuning
Evidence upkeep	Recurring	Compliance or security operations staff	How often ratings are assigned, how many release gate decisions must be recorded, and whether evidence is collected automatically from the tracker
Annual review of the system and process	Recurring, at least once a year	Process owner, security leadership, stakeholders from development	Size of the scale and process, number of exceptions granted since the last review, and changes in threat or regulatory context
External review of the scale	Optional, periodic or event-driven	Independent consultant or assessor selected by the organization	Scope of the review, whether the scale is benchmarked against a recognized method, and how much documentation the reviewer must read
Auditor sampling and testing	Recurring at each assessment cycle	Independent auditor or assessor, paid by the organization	Assessment scope, number of applications sampled, and the quality of records showing ratings, fix order and release decisions
Quote items to request	Written, before work starts	Vendor, implementation partner, or consultant	Ask for the fixed scope, named deliverables, assumptions about application count and tool use, the annual review effort, and which evidence the partner prepares versus what the auditor issues

What your team keeps, what a partner can take on, and what the auditor tests

Safeguard 16.6 asks for a severity rating system and process for application vulnerabilities that sets the order of fixes and a minimum security bar for releasing code. Your organization owns that standard. Someone accountable must decide what the scale means for your products, which severities block a release, who can accept a documented exception, and how the rating ties to your risk appetite. The annual review is also yours to run, because CIS asks for the system and process to be reviewed and updated each year.

The rating standard: the scale, its definitions, and the severity thresholds that map to fix deadlines.
The release decision: the rule that states which open findings stop a release and who signs the exception.
Exception handling: the approval path, expiry dates and compensating controls for findings you accept.
The annual review: a dated record of what changed, who reviewed it and which applications it affected.
Application ownership: named owners who act on ratings for each product and service.

Confirm that your standard is written, approved by a named executive, and linked to the process described in Safeguard 16.2, which the CIS assessment specification treats as a prerequisite.

Where severity rating programs usually fall short

Severity rating programs for Safeguard 16.6 usually fail in predictable places: the scale exists on paper but teams do not use it, ratings never reach a release decision, and the record of review is missing. Each gap below changes what an assessor can verify and what the enterprise can defend.

A scale no team applies

A written scale that engineering teams never use leaves fix order to individual judgment. An assessor looks for ratings attached to real findings, not a policy that names levels. Check a sample of recent tickets or findings from your tracker and confirm each one carries a rating from the documented scale, with the rating basis recorded. Assign one owner who checks this monthly.

Ratings with no release gate

Safeguard 16.6 asks for a minimum level of security acceptability before code or applications are released. A rating that does not block or flag a release fails that purpose. Define the threshold in plain terms, such as which severities stop a release and who may approve an exception, then confirm your pipeline or release checklist enforces it and that exceptions are logged with an approver.

No link to the 16.2 intake process

The assessment specification treats Safeguard 16.2 as a prerequisite for measuring 16.6, so ratings must start where vulnerability reports arrive. Reports from external researchers, scanners and internal testers should enter the same record and receive the same rating method. Confirm that intake tickets carry a severity field and that the timing metrics from intake can be traced to the rating and the fix.

Inconsistent ratings across teams

When two teams rate the same kind of flaw differently, fix order becomes arbitrary and the scale loses credibility. Common causes are vague criteria, scores copied from scanner output without review, and no calibration. Hold a short calibration session on a set of past findings, record the agreed ratings as examples, and check that scanner severities are adjusted with a stated reason where the application context differs.

No record of the annual review

Safeguard 16.6 requires the system and process to be reviewed and updated annually, and the review is what an assessor asks to see. Teams often update the scale informally and never record it. Keep a dated review record listing who reviewed the scale, what changed, the reason, and the approver. Store it with the policy so the version history matches the rating decisions made in the same period.

Questions buyers ask about Safeguard 16.6 cost, effort and help

How much effort does a Safeguard 16.6 severity rating process take?

Most of the effort is in writing the rating scheme and getting teams to use it, not in the document itself. The work breaks into choosing a severity scale, defining how each rating maps to a fix deadline, deciding what rating a release must clear before it ships, and wiring the scale into the tracker where findings already live. Effort rises with the number of applications, the number of teams that triage findings, and how many tools feed results into the process. Safeguard 16.6 is also reviewed and updated annually, so a recurring slice of effort stays on the calendar. Ask any provider to break its quote into design, rollout and annual review, so you can see which part is one-time and which recurs.

Can a small IG2 security team build the Safeguard 16.6 process on its own?

A small team can build it if it has a clear owner, someone who understands how the applications are released, and time to agree the rules with engineering leads. Safeguard 16.6 sits in Implementation Group 2, so it applies once an enterprise has moved beyond essential cyber hygiene, and it depends on Safeguard 16.2, the intake process for software vulnerabilities. If that intake process is weak, the severity rules have nothing reliable to rank. Small teams often struggle less with writing the policy than with enforcing the release bar across several development groups. An outside implementation partner can prepare the scheme and tooling, while your staff keep ownership of the decisions about risk acceptance and release.

How long does it take to build a Safeguard 16.6 rating system?

The timeline depends on drivers you can measure in your own environment, and no reliable general duration applies. The main ones are how many applications and teams are in scope, whether a vulnerability intake process from Safeguard 16.2 already exists, how many scanners and tools must be normalized, and how quickly leadership agrees on fix deadlines and release thresholds. Organizations with existing tracking and a documented intake path usually move faster than those starting from scratch. Ask a provider for a written schedule tied to a fixed scope, with milestones for agreement on the scale, pilot on one or two applications, and rollout across the rest.

What does the rating process need from our own staff?

It needs decisions and participation from people who own risk, not just technical configuration. Your staff must define who sets severity, who can accept a risk, what counts as a blocking finding for a release, and how exceptions are approved and recorded. Application owners and development leads need to review the scale and agree to apply it. Security engineers must confirm the tracker holds the fields the process depends on. These decisions stay with your organization, because Safeguard 16.6 asks for a process your enterprise runs, and an implementation partner cannot make those choices for you.

Are open-source tools enough to meet Safeguard 16.6?

Open-source tools can supply much of the data and workflow, but they do not supply the policy. DefectDojo can import findings from more than 500 security tool report formats and deduplicate them using per-tool hashcode fields, which helps a single view of application vulnerabilities. Greenbone Community Edition, built on OpenVAS, stores scan results in PostgreSQL and schedules tasks, which covers infrastructure-side scanning. Neither tool decides what a critical finding means for your business, sets fix deadlines or blocks a release. Confirm during evaluation which report formats your current scanners produce and whether the workflow fits how your teams already release code.

Can an auditor help us build the Safeguard 16.6 process?

An independent auditor or assessor should not design the process you are later assessed against, because that removes the independence the assessment depends on. Auditors and certification bodies issue reports and certificates, and they test whether your process works. A separate implementation partner can prepare systems, tooling and documentation for you to review, while the assessor later checks the result. Ask any firm to state in writing which role it plays, and keep design work and assessment work with different parties.

How DeployOpen scopes and prepares Safeguard 16.6 evidence

DeployOpen plans, implements and documents the vulnerability severity rating system and process that Safeguard 16.6 asks for, inside your own infrastructure. We prepare the system and evidence, while your organization owns the control and the independent assessor decides whether it meets the requirement.

How we scope

The written scope names the applications, pipelines and teams that the severity rating system must cover.
It defines which vulnerability sources feed the rating process, such as scanners, penetration tests and vulnerability reports.
It sets out the deliverables, owners and review cadence for the annual update before any work starts.

How we build

We draft a severity rating scheme and release criteria that set fix order and a minimum bar for shipping code.
We configure tooling such as DefectDojo to record findings, apply the rating and track fixes against it.
We test the workflow end to end with sample findings so the rating decisions can be traced and reproduced.

How we hand over

We deliver the written rating process, the release criteria and the configuration records as documented evidence.
We walk your engineering and security owners through how to apply the ratings and where each record is kept.
We provide a review checklist so the annual update of the system and process is performed and recorded.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover the annual review of the rating system and updates to tooling as your applications change.
Confirm with DeployOpen during scoping which evidence your independent assessor expects for Safeguard 16.6.