Safeguard 16.2 software vulnerability intake

What the software vulnerability intake process requires and why teams find it hard

Safeguard 16.2 asks an IG2 or IG3 enterprise to establish and maintain a process that accepts and addresses reports of software vulnerabilities, and that gives outside parties a way to make those reports. The process covers the software the enterprise builds, hosts or buys, so a report about a vendor product, a customer-facing API or an internal tool should reach the same path and end in a recorded decision. The question to answer first is simple: if a researcher emailed a flaw to the wrong person today, would anyone know it existed next week?

The risk is less about missing a single report than about reports that never become work. Findings arrive by email to a developer, in a chat channel, through a sales contact or not at all, and nobody can show when they were received, who triaged them or whether the fix was tested before release. An assessor reviewing the Safeguard will look for a documented process and proof that it runs, so a mailbox with no record of handling leaves the enterprise with nothing to show. Fixes that cannot be traced also make it hard to answer a customer or regulator who asks whether a reported flaw was closed.

Teams usually find this hard for three reasons. No single owner is named, so each report waits for someone to claim it. No severity scale is agreed, so one team treats a remote code execution report as urgent while another queues it behind feature work. Tracking is split across a ticket queue, a spreadsheet, a scanner export and a security inbox, so the metrics the Safeguard expects for identification, analysis and remediation timing cannot be produced. Before you build anything, confirm who will own the policy, which severity rating system the process will use (Safeguard 16.6 covers that scale in detail) and which single system will hold every report from intake to retest.

Which software, teams and third parties fall under the intake process

Safeguard 16.2 is scoped by three questions: which enterprise tier applies, which software sits inside the process, and who is expected to route reports into it. Each card below is a scoping decision that changes the size and shape of the work, and the answers should be written down before any tooling is chosen.

Implementation Group placement

Safeguard 16.2 sits in Implementation Group 2, so IG1 enterprises are not measured against it, while IG2 and IG3 enterprises are. Confirm your IG using CIS's Implementation Group definitions before scoping. An IG1 organization that builds software can still adopt the process voluntarily, but the assessment will not test it as a requirement. Record the IG decision and its rationale in the scope document.

In-house developed software

Code your teams write and maintain is the core of the process. Decide which repositories, services and internal tools feed vulnerability reports into the intake, and which team owns each one. Ownership gaps are the most common reason reports stall after intake. Name a responsible party for each product, not only for the organization as a whole.

Hosted and SaaS applications

Applications your organization runs on infrastructure it operates, or on hosted platforms it configures, need intake coverage even when a vendor patches the underlying code. Decide who receives reports about configuration weaknesses, custom extensions and integrations. The line between vendor fixes and your own remediation should be written into the handling policy so reports are not passed back and forth.

Acquired and third-party software

Commercial and open-source software you deploy also produces vulnerability reports. Decide whether the intake accepts reports about acquired products, how it routes them to the vendor, and how it tracks vendor response times. Contracts should state how vendors receive and act on reports, which links to the Control 15 service provider process. Confirm this with procurement and legal before scoping.

Product teams and vendors as report sources

Reports come from more than security staff: developers, operations, customer support, vendors and outside researchers. List each source the intake will accept, the channel each uses, and the team that triages it. Vendors and product teams that already run their own disclosure processes should have a defined hand-off, so the same finding is not tracked twice under different identifiers.

Public-facing applications and the external channel

The external reporting channel must reach every public-facing application in scope, not only the flagship product. Inventory internet-facing applications, APIs and subdomains, then confirm each one is listed on the channel or routed to it. Test the channel by submitting a sample report for an application that is not the main product. Gaps usually appear in older applications and acquired brands.

How an assessor tests the intake process against Safeguard 16.2

This table compares each element of the 16.2 intake process with the evidence an assessor typically requests and the finding that appears most often when that element is weak. Read it as a checklist to run against your own process before an assessment, since the CIS Assessment Specification scores the whole process and a missing process fails the Safeguard outright.

Element	Evidence requested	Common finding
Written policy and responsible party	Approved vulnerability handling policy, named owner, version history and evidence the owner accepted the role	Process exists only in people's heads or in a wiki page with no owner or approval date
External reporting channel	Published contact or form, the mechanism for outside parties to reach the team, and sample reports received through it	Channel is internal only, or the published address is unmonitored and reports sit unanswered
Intake and assignment records	Ticket or case entries showing date received, triage notes and the team member assigned	Reports are logged inconsistently, with no record of who received them or when
Remediation and retest evidence	Fix references (commits or releases), retest results and closure approval for each confirmed vulnerability	Fixes are deployed but never retested, so closure cannot be shown
Tracking system with severity ratings	Tracker export showing severity ratings, status history and a link from each report to its fix	Severity is assigned inconsistently or the tracker lacks status history
Timing metrics for identification, analysis and remediation	Recorded timestamps and reports showing time to identify, analyze and remediate, with stated targets	Metrics are not captured, so timing cannot be measured at all
Annual review of the process and metrics	Dated review record, findings from the review and changes made to the policy or metrics	Review is skipped in the year of assessment or documented without action

What the handling policy and tracking system must contain

A reviewer checking Safeguard 16.2 looks first for a written vulnerability handling policy with a named responsible party, then for proof that the policy runs. The policy should state who owns intake, who assigns work, who approves remediation and who signs off that a fix was tested. Name a role, not a team mailbox alone, and record the backup for that role. The policy should also say how the external reporting channel is monitored, how reporters are acknowledged and what the path looks like from intake to assignment, remediation and remediation testing. Each stage needs an entry point and an owner, so a reviewer can follow one report from receipt to closure without asking the team to reconstruct it.

The tracking system is where the process becomes measurable. Every accepted report should become a record with a severity rating, an assigned owner, a due date and a status that moves through remediation testing before closure. Severity ratings must follow a scheme the organization has defined and applies consistently, so that fix order can be explained. The metrics the Safeguard names are identification, analysis and remediation timing. In practice that means recording when a vulnerability was identified, when it was analyzed and rated, and when it was remediated and verified. Open-source trackers such as DefectDojo can hold these fields when findings are imported from scanners and code checks, but confirm the exact fields and timestamps your version stores before you rely on them for reporting.

A policy on its own does not satisfy this Safeguard. The assessment looks for records that show the process operated, including reports received through the external channel, rated and assigned findings, remediation tickets, test results and closure dates. Build a review step into the calendar: the Safeguard calls for the process and metrics to be reviewed annually, so keep dated review records showing what changed, such as an adjusted severity scheme, a new intake channel or a missed timing target and its fix. Before an assessment, sample a few closed records end to end and confirm that each step left evidence. Gaps found in that sample are easier to fix now than during an assessor's testing.

How to build the intake process step by step

This sequence turns Safeguard 16.2 from a written intention into a working path: a named owner, a public reporting channel, a severity scale, a tracked workflow, retest criteria and metrics that can be reviewed each year.

Name the responsible party and approve the policy
Assign one accountable owner for software vulnerability handling, usually the head of product security or the engineering lead who can direct fixes across teams, and name a deputy for coverage. Draft a vulnerability handling policy that states the scope, the responsible party, the intake and remediation stages, and the review cycle, then have executive leadership approve it. Done means a signed or recorded approval, a named owner and deputy, and a policy version number that auditors can trace to the date it took effect.
Publish the external reporting channel
Create a single, documented way for outside researchers, customers and partners to report software vulnerabilities, such as a monitored security mailbox or a web form, and publish it where reporters will look. Define an acknowledgment process that tells the reporter the report was received, who owns it and how updates will reach them, and assign a person to watch the channel during business hours. Done means the channel is live, a test report reaches the owner, and the acknowledgment template is approved and stored with the policy.
Define the severity scale and intake fields
Adopt a severity rating scale for software vulnerabilities and write down what each level means in terms of exploitability and business impact. Build the intake form so every report captures the same fields: affected product and version, component, reproduction steps, reporter contact, data exposure, and the severity assigned at triage. Ask the security team to confirm the scale with the rating criteria used in Safeguard 16.6 so the two stay consistent. Done means a documented scale and a fixed field list approved by the policy owner.
Connect intake to tracking and assignment
Route every accepted report into a tracking system where each finding gets a unique identifier, a severity, an assigned engineering owner, a target state and a link to the code or product affected. If you use DefectDojo, an open-source vulnerability management platform, you can import findings from scanners and manual reports into one place and use its deduplication to avoid duplicate tickets. Document the workflow states from intake through assignment, remediation, remediation testing and closure. Done means a test report moves through every state with an audit trail.
Set remediation and retest criteria
Write the conditions that let a finding close: the fix is merged through the protected change process, the affected version is rebuilt and deployed, and a tester confirms the original issue no longer reproduces. Require a second person or an automated check to verify the fix before closure, and record who performed the retest and when. Confirm with the policy owner which findings need a formal root cause review under Safeguard 16.3. Done means every closed item has a retest record and no finding can close on the developer's word alone.
Configure metrics for identification, analysis and remediation
Configure the tracking system to record the dates for identification, analysis and remediation of each finding, so you can measure how long each stage takes and by severity. Set up dashboards or exported reports that show open items by severity and age. Confirm the metric definitions in writing, because Safeguard 16.2 expects metrics for these three stages and the assessor will ask how each is calculated. Done means a report can show the metrics for a sample of findings without manual reconstruction.
Dry run with a test report
Submit a test report through the external channel, using a clearly labeled, non-sensitive finding in a non-production application. Follow it through acknowledgment, triage, severity assignment, assignment, fix, retest and closure, and note every point where the process stalled, the form was unclear or the owner was missing. Update the policy, form, workflow or dashboard to fix what the dry run exposed, then rerun the test if the change was material. Done means a written dry run record with the timestamps, the gaps found and the changes made.
Schedule the first annual review
Put the first annual review of the policy, severity scale, workflow and metrics on the governance calendar, with the policy owner and the metrics owner named as attendees. The review should check the dry run findings, the metrics from live reports and any changes in the reporting channel or product scope, then record decisions and update the policy version. Confirm the review date with your own governance calendar and with the assessor's expectations, since the review cycle is part of what the safeguard requires. Done means a dated calendar entry and a review template ready before the date arrives.

Which evidence shows the intake process works

An assessor testing Safeguard 16.2 will look for a chain of records that runs from a vulnerability report through a ticket, a fix and a retest, all governed by a written policy and reviewed each year. Each card below is one artifact in that chain, with a note on keeping it current between assessments.

Signed vulnerability handling policy

This is the written process that defines how reports are accepted, who is the responsible party, how findings move from intake to assignment, remediation and retest, and how severity is set. Record the named owner, the approval date and the approver's signature or sign-off record. Keep a change log so every revision shows what changed, who approved it and when. Between assessments, confirm the policy still names the current owner and that the version on file matches the one teams actually follow.

Published external reporting channel

Safeguard 16.2 requires a means for outside parties to report software vulnerabilities. Keep a screenshot or export of the published page or security contact, the mailbox or form configuration, and a record of who monitors it. Test the channel on a schedule with a dummy report and file the result. Confirm that reports from outside the company reach the same tracking system as internal findings.

Intake tickets with assignment and dates

A sample of tickets shows each report moving through intake, assignment and remediation with timestamps. Choose a sample that covers internal scanner findings and external reports, then check that each ticket names an assignee and a due date based on severity. Missing timestamps or unassigned tickets are common gaps. Ask the team to explain any ticket that sat without an owner for longer than the policy allows.

Remediation and retest records

Each finding should link to the fix, such as a merged change or patched release, and to a retest record that confirms the vulnerability no longer reproduces. Without the retest, the ticket only shows that someone said the issue was fixed. In DefectDojo or a similar tracker, keep the link between the finding, the fixing change and the verification result, so an assessor can follow one finding end to end.

Severity ratings and exported metrics

The tracking system should hold a severity rating for each finding and produce metrics for identification, analysis and remediation timing. Schedule exports of these metrics, such as monthly CSV or report snapshots, and store them with the date they were produced. Snapshots matter because a live dashboard shows only the current state, while assessors need to see trends over the review period.

Annual review record

Safeguard 16.2 expects the process and its metrics to be reviewed each year. Keep minutes or a sign-off that records the review date, attendees, the metrics examined and the changes agreed. Log any policy or severity threshold changes made during the year. Confirm with your assessor what form of review record they accept, since the expected format depends on the audit or assurance scheme in use.

What meeting Safeguard 16.2 costs in money and effort

This table lists the cost components of running a software vulnerability intake process under Safeguard 16.2, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to shape a written scope and ask each provider for the same assumptions before comparing quotes.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Mostly one-time setup, then recurring if paid tiers are chosen	Number of applications, whether a commercial tracker is bought, and hosting choices. The CIS Controls are free for internal use, so the main spend is the tracker and its hosting.	Use an open-source tracker such as DefectDojo (BSD-3-Clause) self-hosted in your own environment, and confirm the license of each tool before adoption.
Engineering and security staff time to write the policy and set up intake	One-time, with periodic updates	Number of teams involved, existing secure development process, and whether a responsible party is already named	Reuse existing policy templates and the process from Safeguard 16.1 where it exists, and agree a single responsible owner early.
Operating time for triage, assignment and retest	Recurring	Volume of external and internal reports, severity mix, and how many teams fix code	Automate deduplication and import of scanner output, and define severity ratings in advance so triage has clear rules.
Evidence upkeep and annual review	Recurring, at least yearly	How many records must be kept, whether metrics are produced by hand, and the number of systems in scope	Generate metrics from the tracker's data rather than spreadsheets, and store intake records in one place.
External testing or review of the reporting channel	Recurring or per engagement	Scope of the channel, whether an outside party tests intake, and the number of applications covered	Ask for a written scope that names the channel, the applications and the deliverables, and test only what the policy covers.
Auditor or assessor sampling	Recurring, at each assessment cycle	Number of reports and remediation records the assessor samples, and how easily records can be retrieved	Keep a complete, time-stamped record for every report from intake to retest so samples can be pulled quickly.

Which self-hosted open-source tools can support the intake evidence

Safeguard 16.2 asks for a working intake process, and the records it produces are what an assessor will sample. The four tools below each cover one part of that trail: findings consolidation, scan results, change control on fixes and scanning inside the build pipeline. None of them makes the process compliant on its own, and the organization must confirm each capability in its own environment before relying on it.

Consolidating findings in DefectDojo

DefectDojo (BSD-3-Clause) 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 for anything else. It deduplicates findings using per-tool hashcode fields, so one reported weakness does not appear as several tickets. The evidence is a findings register with tool, date and status history, which can show intake and tracking together. Check that your reporting tools export in a supported format, that the hashcode fields match your scanners, and that the BSD-3-Clause license fits your use.

Scheduling scans with Greenbone Community Edition

Greenbone Community Edition (OpenVAS) runs through gvmd, which schedules scan tasks, manages users and permissions, and stores results in PostgreSQL. Users run scans and review results in the Greenbone Security Assistant web interface. The evidence is a dated scan history with results that show which findings were raised and when. Confirm that the scan scope covers the applications and hosts you need to report on, and review the AGPL-3.0-or-later terms if you plan to modify and offer the software to others.

Protecting fix branches in GitLab

GitLab Community Edition (MIT) supports protected branches, which let maintainers restrict which roles can push or merge to a branch. Setting push access to no one blocks direct pushes, and force pushes stay disabled unless explicitly allowed. Fixes for reported vulnerabilities then pass through a reviewed merge request, which leaves an auditable change record. Confirm which roles hold merge rights on release branches, and check whether your required approvals and remediation testing are enforced by the pipeline rather than by convention.

Scanning code in CI/CD with Semgrep

Semgrep Community Edition (LGPL-2.1-only) scans code in languages including C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, using community or custom rules. It can run in CI/CD pipelines so repositories are scanned on every change. Its output gives a record of code-level findings that can feed the intake register, and custom rules can target vulnerability classes that reported issues reveal. Confirm that your languages are covered by the rule set in use, and review the LGPL-2.1-only terms with your legal team before distribution.

Who owns the intake process, who can help and who issues the assessment

Your organization owns Safeguard 16.2 in full. The process only counts as implemented if people inside the enterprise have written the vulnerability handling policy, named a responsible party, and make the triage and fix decisions when reports arrive. An outside partner can set up tools, but it cannot accept risk on your behalf or decide that a reported flaw in your product is acceptable. Internal owners also need to know what the assessment specification will look for, because the evidence is generated during normal work rather than assembled at audit time.

Policy and responsible party: Approve a written handling policy that states who receives reports, who assigns them, and who signs off on remediation. Name a responsible party with authority across the development teams that build the software.
Triage decisions: Decide severity, priority and whether a report is valid. Record the reasoning, because a reviewer will sample these decisions and check that they follow the policy.
Fixes and retesting: Development teams make the code changes and confirm that the fix addresses the root issue. Retesting should be recorded against the original report.
Tracking and metrics: Operate the tracking system with severity ratings and timing measures for identification, analysis and remediation, and review them at least annually as the safeguard describes.
Ask before you start: Confirm who in your organization is accountable if a report is missed, and who can overrule a team that wants to defer a fix.

Before engaging anyone, check that these internal roles are named in writing and that someone can produce the records for a sample of reports within a short notice period.

Where organizations usually fall short on Safeguard 16.2

Most gaps under Safeguard 16.2 are not missing tools. They are missing decisions: who can receive a report, who owns the policy, how findings are ranked and how a fix is proven. Each card below names one gap and the single action that closes it.

No external reporting channel

The safeguard requires a means for outside parties to report software vulnerabilities. Many organizations only list an internal mailbox that customers, researchers and partners cannot find or trust. Check whether a public, monitored address or web form exists, is named on the website or security page, and has a documented owner who reads it during working hours and acknowledges receipt.

Policy with no owner

A vulnerability handling policy is only evidence if a named role is responsible for it and the approving leaders have signed it. Drafts that sit in a shared folder, or that reference staff who have left, fail the documentation test. Assign a responsible party, record the approval, and set the date for the annual review that the process requires.

Reports tracked in chat

When reports arrive in email threads or chat channels, there is no record of who received them, who was assigned them or when work started. An assessor will ask to see the path from intake to assignment for a sample of reports and will find gaps. Move each report into a tracking system with an owner field and timestamps, even if the first step is a single shared queue.

No shared severity scale

Without a written severity scale, two engineers can rate the same flaw as urgent and routine. Triage then depends on who happens to read the report. Define the rating levels, the criteria for each, and who may change a rating. Apply the scale in the tracker so every record carries a severity value that can be reported and reviewed.

Fixes closed without retest

Safeguard 16.2 includes remediation testing, so a ticket marked done is not enough. Teams often close a finding when the code merges, without confirming the vulnerability is gone in the deployed build. Require a retest step before closure, record who performed it and the result, and link the retest evidence to the original report.

No metrics or annual review

The process should measure identification, analysis and remediation timing, and the policy should be reviewed each year. Organizations often collect none of these numbers, or they exist in ad hoc spreadsheets that nobody reviews. Pick the timing measures your tracker can produce, set a recurring review date on the governance calendar, and keep the minutes or sign-off as evidence.

Questions buyers ask about Safeguard 16.2 before hiring help

How much effort does a software vulnerability intake process take to set up?

Setup effort depends mainly on how many products and repositories are in scope, how many teams ship software, and whether intake already exists in some form. Most of the work is documentation and workflow design: a handling policy, a named responsible party, an intake channel, triage and assignment rules, a remediation testing step, and a tracking system with severity ratings. Tooling adds effort only if the organization must integrate scanners or bug trackers. Ongoing effort is recurring: triage, assignment, tracking, the annual review that Safeguard 16.2 expects, and reporting on timing metrics. Ask any provider to break the estimate into one-time design work and recurring operations before you compare quotes.

Can an IG2 enterprise build a software vulnerability intake process in-house?

Yes, if the organization has people who can write the policy, run triage and verify fixes. Safeguard 16.2 applies from Implementation Group 2, so IG2 and IG3 enterprises must meet it, and nothing in the Safeguard requires an outside firm. The usual gaps are not technical. They are a clear owner, a published channel that outsiders can find, consistent severity definitions, and records that show each report moved from intake to tested remediation. An internal team can close those gaps, or it can bring in a partner to prepare the systems and tracking workflow while keeping ownership of the decisions.

What does the intake process need from engineering, security and legal?

Each function has a distinct role, and the organization owns all of them:

Security owns the handling policy, severity ratings, triage and the tracking system.
Engineering owns assignment, fixes, root cause follow-up and remediation testing for the affected product.
Legal reviews the public disclosure terms, the scope of safe-harbor language for researchers and any contractual notice duties to customers.

Product owners approve remediation timing when a fix affects a release. Write these roles into the policy so that a report never waits for someone to decide who is responsible.

How long does it take to set up a vulnerability intake process?

Timing depends on the agreed scope, and no duration can be stated responsibly without it. The scope sets how many products, teams and systems must be covered, whether tooling must be built or only configured, and how many approval cycles the policy needs. Ask any provider for a written schedule tied to named deliverables, and ask which parts depend on your internal reviews. DeployOpen plans its engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts.

Do the CIS Controls require an external reporting channel by name?

Safeguard 16.2 asks for a process to accept and address reports of software vulnerabilities, and it expects that process to include a way for outside parties to submit reports. In plain terms, the organization must give people outside the company a route to tell it about a flaw, and must then handle what arrives. The Safeguard does not name a specific product, email address, web form or disclosure platform. Choose a channel that matches your products and your customers, publish it where researchers and customers will look, and keep records that show it works.

What will an auditor ask to see for Safeguard 16.2?

An assessor will usually ask for the documented process and check that it covers each stage the Safeguard names: intake, assignment, remediation, remediation testing and tracking. Expect requests for the vulnerability handling policy, the named responsible party, the published external reporting channel, and a sample of reports traced from intake through tested fix. The tracking system should show severity ratings and metrics for identification, analysis and remediation timing, and records should show an annual review. Under the CIS Controls Assessment Specification, a missing process fails the Safeguard, so the evidence must exist before the assessment begins. Confirm with your assessor which artifacts they accept in your environment.

How DeployOpen scopes and prepares the intake process

DeployOpen plans and implements the systems and documentation behind Safeguard 16.2 software vulnerability intake inside your own infrastructure. The organization owns its policy and decisions, and an independent auditor or assessor reviews the evidence and issues any report.

How we scope

The written scope names which applications, repositories and vendors fall under the intake process.
Scope also confirms the external reporting channel, the responsible party and how reports reach remediation.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.

How we build

Configure a DefectDojo instance to import findings, deduplicate them and track severity ratings and remediation dates.
Set up GitLab protected branches and Semgrep scans in CI/CD so reported issues link to controlled code changes.
Draft the vulnerability handling policy and intake workflow for your review and approval by your own staff.

How we hand over

Deliver configuration records, workflow documentation and sample tickets that show intake through remediation testing.
Provide metric definitions for identification, analysis and remediation timing, plus an annual review procedure.
Walk your team through operating the tracker so the evidence stays current after the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, if your organization wants them.
Retainer work can cover tool upgrades, workflow changes and refreshing the metrics used in the annual review.
Confirm with your auditor which evidence formats they accept before the handover is finalized.