ServiceNow Vulnerability Response: Roles, Responsibilities and RACI

Core Roles in Vulnerability Response

The Chief Information Security Officer (CISO) sets strategic direction for vulnerability management: risk appetite, remediation timelines and resource allocation. The Vulnerability Manager owns the overall vulnerability response program: metrics, processes and tool administration. The Vulnerability Analyst triages vulnerabilities and assesses severity. The System Owner operates systems and is responsible for remediation: they install patches and fix configuration issues. The Infrastructure Team provides hosting, database and network support that may be needed for remediation. The Security Operations Center (SOC) monitors for vulnerability exploit attempts and escalates threats.

RACI Matrix for Key Decisions

Severity assessment: Vulnerability Analyst is Responsible, CISO is Accountable, System Owner is Consulted, SOC is Informed. Patch schedule: System Owner is Responsible, Vulnerability Manager is Accountable, CISO is Consulted, Infrastructure Team is Informed. Temporary mitigations: SOC is Responsible for immediate action, System Owner is Accountable for permanent fix, Vulnerability Manager is Consulted, CISO is Informed. Waiver decisions: System Owner is Responsible for business justification, CISO is Accountable for approval, Vulnerability Manager is Consulted, Finance is Informed. Disclosure decisions: CISO is Responsible, Chief Legal Officer is Accountable, Public Relations is Consulted, Executive Team is Informed.

Vulnerability Assessment Responsibilities

Vulnerability Analyst responsibilities: run regular vulnerability scans, triage findings to identify true risks versus false positives, assess severity based on asset criticality and exploit likelihood, create remediation tasks with clear findings and fix instructions, escalate zero-day or imminent threats immediately. System Owner responsibilities: understand vulnerabilities affecting their systems, estimate remediation effort and timeline, assign remediation tasks to technical staff, test patches in non-production before deployment, report status regularly to Vulnerability Manager. Infrastructure Team responsibilities: provide patches and security updates for infrastructure components, test patches for compatibility with production workloads, schedule maintenance windows for deployment, assist with post-remediation validation.

Escalation and Decision Paths

Critical vulnerabilities (CVSS 9+, active exploits): alert CISO immediately, escalate to Executive Team, activate incident response procedures. High vulnerabilities (CVSS 7-8, significant impact): Vulnerability Manager reviews and estimates effort, discusses remediation timeline with System Owner and CISO, schedules patches. Medium vulnerabilities (CVSS 4-6, moderate impact): System Owner plans remediation, Vulnerability Manager follows up monthly. Low vulnerabilities (CVSS 0-3, minimal impact): System Owner plans for next scheduled maintenance, no urgent escalation needed. If a System Owner cannot remediate within agreed timeline, they request a formal waiver: CISO reviews the risk and business justification, approves or requires accelerated timeline.

SLA and Metrics

Critical vulnerabilities: remediate quickly or declare a temporary mitigation (firewall rule, network isolation, service disable). High, medium, and low vulnerabilities: remediate within windows set by your policy, with each lower severity given a longer window. Metrics tracked: vulnerability backlog (open remediation tasks), mean time to remediation by severity, waiver approval rate, false positive rate of scans, re-scan compliance (percentage of systems receiving regular scans).

Ownership Gaps and Common Issues

Gap one: unclear ownership of infrastructure vulnerabilities. Establish that Infrastructure Team owns patches for these layers and System Owners own application-level remediation. Gap two: System Owners do not test patches before production deployment, causing outages. Require testing in non-production and sign-off from System Owner. Gap three: High volume of false positives consumes remediation effort. Invest in improving scan accuracy so Analysts spend time on real issues. Gap four: Remediation timeline is unknown. Require System Owners to estimate remediation effort when a remediation task is assigned. Gap five: Waivers accumulate without review. Review all active waivers quarterly and re-justify or close them.

Vulnerability Manager Authority and Boundaries

The Vulnerability Manager has authority to: prioritize vulnerabilities based on risk, escalate non-compliance to CISO, access all systems for scanning, require remediation status updates. The Vulnerability Manager does not have authority to: force System Owners to remediate faster than they estimate, approve business waivers (CISO only), change production systems directly. The Vulnerability Manager coordinates; the System Owner executes. Clear role boundaries prevent conflicts and ensure accountability.

Integrating Vulnerability Response with Incident Management

When an exploit occurs and an incident is opened, link it to the corresponding vulnerability. If the vulnerability was known but not remediated, investigate why. If it was unknown, analyze how it was missed in scans. Use incident data to calibrate vulnerability severity: if a low-risk vulnerability was exploited, reconsider its risk rating. Update the vulnerability program based on lessons learned.

Why a responsibility chart is not yet a working decision path

A responsibility chart answers the question of who is generally involved in a kind of decision. It does not answer who acts first on a Tuesday when the owner of a host has just changed teams, the vendor has not released a fix, and the change calendar is closed for the month. Working decision paths need one more layer: the trigger that starts the decision, the named person who holds it at that moment, the people who must be told, and the record showing that the decider held the authority to decide. Most programs have the first layer on paper. Few have the other three in a form that someone can follow under pressure.

The gap shows up most often at the seams between teams. The chart may assign a task to the system owner, but the system owner is a role, and the role has to be filled by a person with a name, a backup and an authority limit. When that person leaves or moves, the chart stays the same while the decision path quietly changes. Writing the chart as roles with named holders, reviewed on a fixed cycle, closes most of that gap.

Scenarios that test the chart before a real case does

Walk the chart through a short set of realistic situations and write down who acts, who approves and what record proves it. The scenarios below are illustrative. Use them as a test script, not as a description of any particular organization.

Illustration only: a team that runs a small internal application on a host that a different group patches. The application team assumes the host group will close a weakness, the host group assumes the application team has accepted it, and the vulnerability record shows an open task with no active owner. Neither group has done anything wrong by its own reading of the chart. The fix is to name the holder of the decision in the record itself, not in the chart, so that the question “who is responsible now” has one answer that the platform can show.

Delegation of authority that survives leave and turnover

1. Name a primary holder and a deputy for every role that can approve a remediation or an exception, and write both names into the role record rather than into a document.
2. State the authority limit for each holder in plain terms: the severity band, the type of system and the type of decision they can make without a second approval.
3. Set a review date for each delegation, and make the review a recorded decision rather than a reminder that gets dismissed.
4. When a holder leaves or changes teams, reassign their open decisions the same day, and check that no decision is left with a name that no longer works in the organization.
5. Test the path once a quarter with a real open item, and record how long the decision took and who made it.

Writing the handover between owners

A handover between owners is where accountability most often disappears. The outgoing owner knows which exceptions are fragile, which hosts were excluded for a reason and which patches were delayed for a business event. None of that is in the platform unless someone puts it there. A useful handover note lists the open tasks, the exceptions with their review dates, the hosts with special handling and the people outside the team who need to be told about any change. The note goes into the record of each affected item, so that the next person to read the item sees the context without asking anyone.

The same discipline applies when a team member moves out of the program. Access, delegation and task ownership should be removed together, and the process is the same one used for other platform roles. The guidance on offboarding controls covers the controls for a coordinated offboarding handover.

Signs the roles are working and signs they are not

• Open tasks have a named holder and a deputy, and no task has waited for an owner to be assigned for longer than the team considers acceptable.
• Exceptions are approved by the person named in the delegation, and the approval date falls within that person’s authority.
• Escalations reach a person who can decide, rather than a group that forwards them.
• Remediation changes carry the name of the person who approved them, through the change process, and the same name appears in the delegation record.
• The chart is reviewed on a set cycle, and the review changes at least one entry when the organization has changed.

If several of these are not true, the chart is describing an intention rather than a process. The fix is usually to name people, not to add a new row to the chart.

Frequently asked questions about roles

Is it acceptable for a single person to wear two hats?

Yes in a small team, but keep the decisions apart. Triage and closure approval should sit with different people, and whoever accepts an exception should not also be its only reviewer. Where one person must hold two roles, record which decision they made in each capacity and add a second approver for the closures that matter most.

Who speaks for a system owner who is on leave?

The deputy named in the delegation record. If no deputy is named, the decision waits in the queue and the escalation path takes over, which is the reason the deputy should be named before the leave starts rather than during it.

Should a vendor appear in the responsibility chart?

As a responsible party with a named contact inside the organization, yes. The internal owner of the vendor relationship should hold the decision on the vendor’s response, and the chart should say what the vendor is expected to provide and when the organization will act without them.

How often should the chart be reviewed?

On a fixed cycle that the risk owner agrees, and also after any reorganization, acquisition or major change of vendor. A chart reviewed only when someone remembers it will drift from the way decisions are actually made.

Next step for the roles and decision paths

The group concept helps when the team works out how groups and individual holders relate in the platform.