CIS Safeguard 17.1 incident handling lead and backup

What CIS Safeguard 17.1 asks for and why it is often failed on paperwork

Safeguard 17.1 asks you to designate one key person and at least one backup to manage incident handling, with the job of coordinating and documenting response and recovery. The person can be an employee, a service provider or a mix of both. If any part of the work sits with a provider, at least one internal person must oversee it, and the designation must be reviewed annually or after a significant change in the enterprise. Because this is an Implementation Group 1 Safeguard, it applies to every enterprise, including a small team with no security staff. It is not an optional extra for organizations that are already mature.

The risk behind this Safeguard is simple. During an incident, people lose time asking who decides, who can take a system offline, who talks to the regulator and who holds the evidence. A named lead and a named backup remove that delay. Without a backup, a single holiday, resignation or illness can leave the response with no owner. Without internal oversight of an outside provider, the enterprise can end up with a contractor running containment that nobody inside has approved or understands. The Safeguard is short, but it forces a decision that many organizations never write down.

Assessors usually find this Safeguard failed on documentation, not on tooling. The CIS Controls Assessment Specification scores it on whether the enterprise has a document that designates incident handling personnel, and on how complete that record is for the people named. A ticketing system or case tool does not satisfy it alone. Confirm three things before you start: that the designation names real people with contact details, that the backup has the same access and authority as the lead, and that the document records who oversees any provider. The most common gap is a designation that lists a job title with no name, or a backup who left the company two years ago. Check the Safeguard text and the assessment specification directly, using the link to the CIS Controls Assessment Specification, before you write the record.

Which teams, providers and records fall under Safeguard 17.1

Safeguard 17.1 is short, but a few scoping decisions determine how much work the designation creates. The choices below cover who fills the roles, which parts of the enterprise the designation reaches, how many people stand behind the lead and what forces a fresh look at the documentation. Settle them before writing the designation, because each one changes what the documentation must name.

Employees, provider or hybrid staffing

Decide whether the lead and backup are internal staff, a managed security or incident response provider, or a mix of both. The Safeguard allows all three, but a provider-only model still needs at least one internal person who oversees the provider's work. Check whether the named internal overseer has the authority to commit resources and make containment decisions, and whether the provider's on-call arrangements are written into the designation.

Business units and asset scope

Work out which business units, systems and data sets the designated personnel will cover. Safeguard 17.1 is assigned to the Users asset class and the Respond security function, so the designation must match how incidents reach the response team in practice. An incident in a subsidiary, a cloud account or an operational technology segment that no named person covers is a gap an assessor can find.

Number of backups

The Safeguard requires one key person and at least one backup, so two named people is the floor. Consider how many people can cover time zones, holidays and leave, and whether the backup has the same access and decision rights as the lead. An enterprise with a single security team may need more depth than an enterprise with a provider on retainer. Confirm the backup can act without waiting for the lead.

Review triggers

The designation is reviewed annually and after significant enterprise changes, so define in advance what counts as significant. Typical triggers include a merger, a new cloud environment, a reorganization of the security team, a change of managed service provider and the departure of the lead or backup. Record each review and its outcome, since an assessor will ask for evidence that the review happened and not just that a policy requires it.

Provider change and contract terms

When a service provider is replaced, the designation must be updated and the new provider's responsibilities must be documented. Check that the contract names the provider's incident handling contacts, response times and escalation path back to the internal overseer. Confirm how the provider hands over open cases, logs and evidence at exit so the internal team keeps the records it needs.

Records that prove the designation

The evidence is a document naming the lead and backup, their roles and the internal oversight arrangement, along with the review history. Decide where this record lives, who can edit it and how old versions are kept. A versioned wiki or document system makes it easy to show when a name changed and who approved the change, which is the kind of trail an assessor tests.

How an assessor tests Safeguard 17.1 under the CIS Controls Assessment Specification

This table walks through each check an assessor makes against Safeguard 17.1, the evidence requested for it and the findings that most often fail the measure. Read it as a checklist for your own documentation before an assessor reviews it, since the specification scores documentation completeness rather than how well a person performs in an incident.

Assessment check	What the assessor looks for	Evidence requested	Common findings
Designation exists	A written record naming the key person who manages incident handling and coordinates response and recovery	Signed or approved designation document, or a policy section that names the role holder	No documentation designating incident handling personnel, which receives a failing score under the specification
Backup designated	At least one named backup who can take over the key person's duties	Designation record listing the backup alongside the lead	Only one person is named, or the backup is named in conversation but not in the documentation
Completeness of components	Whether the documentation includes all the components the specification expects for the designated personnel, such as who they are and what they manage	The designation record checked against the components the specification lists	Names appear without roles, contact routes or scope, so the Completeness share is partial
Provider oversight	If a service provider handles incidents, at least one internal person is named as overseer of that provider's work	Contract or service description plus the named internal overseer in the designation	Provider is named as the response team with no internal person accountable for its work
Review cadence	Evidence that the designation is reviewed annually and after significant enterprise changes	Dated review records, change log or approval history for the designation	Undated designation, or a review date that has passed with no re-approval
Current accuracy	Whether the named people still hold the roles and can be reached	Comparison of the designation with the current staff list and provider contract	Designated person has left the organization or moved role, and the record was not updated

How to designate the lead and backup in six steps

This sequence turns Safeguard 17.1 from an intention into a documented designation that names who leads incident handling, who backs them up, who oversees any provider, and who keeps the record current. Each step ends with an artifact an assessor can inspect.

Confirm the incident handling scope
Define which incidents, systems, business units and jurisdictions the designated people will cover, using the enterprise's existing incident response process and asset inventory as the starting point. Involve legal, IT operations and security so the scope matches the enterprise's real reporting duties. The output is a short scope statement that the lead and backup can point to when a question about responsibility arises.
Choose the staffing model
Decide whether incident handling will be staffed by employees, a service provider or a hybrid of both. Safeguard 17.1 permits all three, so the choice should reflect where the enterprise has skills, hours of coverage and contract arrangements already in place. The output is a recorded staffing model with the reason for the choice, which the management team approves.
Name the lead and at least one backup
Appoint one key person to manage incident handling and at least one backup who can take over. For each role, write the responsibilities for coordinating and documenting response and recovery, the decisions the role may make, and how the role is reached outside working hours. The output is a named lead, a named backup and a responsibilities table that both people have acknowledged.
Assign internal oversight for any provider
If a service provider performs any part of incident handling, name at least one internal person who oversees that work. This person checks the provider's activity against the agreed scope, receives its reports and escalates gaps to the lead. The output is a named internal overseer recorded against each provider, plus a reference to the contract clauses that give the enterprise visibility into the provider's work.
Record the designation in a controlled document
Write the designation into a controlled document with a version number, an accountable owner, an approval record and an effective date. Store it where the incident response team can reach it during an outage, and keep the contact details current. The output is a dated, approved document that an assessor can match against the names in your staff and provider records.
Set the annual and change-triggered review
Schedule the designation for review at least once a year and whenever a significant change affects the enterprise, such as a reorganization, a new provider, a merger or a departure from the role. Name the reviewer who owns this check and define what evidence of review will be kept. The output is a review calendar entry, a named reviewer and a log that records each review and any change to the designation.

Evidence that passes Safeguard 17.1 and how to keep it current

An assessor testing Safeguard 17.1 looks first for documentation that names the people responsible for incident handling. The artifacts below connect that designation to contacts, oversight of any provider, and a dated record of reviews, so the evidence stays accurate between assessments.

Signed designation document

This is the core artifact. It names the key person and at least one backup, states what each is responsible for in coordinating and documenting response and recovery, and records approval by an accountable executive. The Completeness metric in the assessment specification counts the components this document includes, and a missing designation scores as a failure. Check that the names, roles and approval date match the current staff list, and keep each signed version rather than overwriting it.

Contact and role record

Each designated person needs a current record with a primary contact method, an alternate route, time zone and on-call availability. This is the working list responders use during an incident, so it must be checked against HR and provider records. Confirm the lead and backup are reachable outside the systems that an incident might compromise. Owned by the security operations manager or HR partner, with a review date stamped on each change.

Provider oversight assignment

Where a service provider handles some or all incident work, the designation must show that at least one internal person oversees that work. Record the provider, the scope of its incident duties, the internal overseer and the escalation path between them. An assessor will check that the overseer's name appears in the designation and that the provider's contract references the same responsibilities. Ownership usually sits with the vendor risk or procurement function.

Internal overseer scope

The internal overseer needs a written scope that describes what they must review, approve and escalate, such as provider run books, shift handovers, incident reports and access the provider holds to enterprise systems. Without this scope, oversight cannot be shown in practice. Ask the overseer to sign acceptance of the scope, and keep dated evidence of a periodic check, such as a sample of provider tickets reviewed against the scope.

Review log for annual and triggered reviews

Safeguard 17.1 requires the designation to be reviewed annually and after significant enterprise changes, such as a merger, a new provider, a reorganization or the departure of a named person. The review log records each review date, the reviewer, the trigger, the outcome and any change made. Assessors commonly sample this log against the organization's change history, so gaps between a reorganization and a review are a recurring finding. Owned by the compliance lead.

Handover and change records

When a lead or backup leaves, changes role or goes on extended leave, a handover record shows who took over, what open incidents and access were transferred, and when the designation was updated. These records prove the designation stayed accurate in practice, not only on paper. Keep them alongside the designation versions so each handover can be traced to a dated revision. Confirm that access revocation for departing staff is recorded in the same entry.

What meeting Safeguard 17.1 costs in money and effort

This table lists each cost component of Safeguard 17.1, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request, because no price or duration is published for this Safeguard and the real figures depend on your enterprise size, provider use and review triggers. The main takeaway is that open-source tools remove license spend but not the staff time to designate, train and oversee.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Staff time to choose and train the lead and backup	One-time at designation, plus refresher time. Paid through internal salaries or a provider's fees	Number of candidates, existing incident experience, and how many people already hold response duties
Role and documentation work	One-time to write the designation record, then updated on change. Internal staff or provider time	Whether an existing response plan can be extended, and how many systems the record must reference
Provider fees if a service provider holds the role	Recurring under the contract. Paid to the provider, with fee structure set in the agreement	Scope of incident handling, hours of coverage, and whether a backup is also contracted
Internal overseer time	Recurring. Paid through internal salaries, since at least one internal person must oversee any provider's work	Number of providers, frequency of reporting, and the size of the provider's remit
Review upkeep	Recurring. The designation is reviewed annually and after significant enterprise changes, so this cost is paid internally	Rate of organizational change, mergers, new providers, and staff turnover in the lead or backup roles
Auditor sampling time	Recurring at each assessment. Paid to the independent auditor, with the organization preparing the records	Number of designation records and their clarity, and whether the evidence sits in one place
Open-source record system	One-time setup and recurring hosting and maintenance. No license spend, but staff or partner time applies	Choice of hosting, how many users need access, and how much integration is required with other tools

Who owns the designation, who can help and where the auditor stops

Your organization owns Safeguard 17.1. Leadership must decide who the key incident handling person is and who backs them up, whether those people are employees, a service provider or a mix of both. Under the Safeguard, the designation has to be documented, and the choice of personnel is a management decision that no outside party can make on your behalf. Your team also signs off on the record and keeps it current, including the annual review and any review triggered by significant enterprise changes.

Naming the people: Decide the lead and at least one backup, and confirm each person accepts the role and has the authority to act during an incident.
Overseeing any provider: If a service provider handles any part of incident handling, name an internal person who oversees its work.
Approving the record: Management approves the designation document and its version history.
Running the annual review: Schedule the review and re-review after reorganizations, mergers or major changes to systems or staffing.
Keeping contact data current: Ensure the people named can be reached through the channels defined for incident handling.

Confirm that your own policy assigns authority for this designation and that the named people have seen the document.

How self-hosted open-source tools keep the designation record current

The designation itself is a document, and the evidence an assessor looks for is proof that the document names the right people and that someone reviewed it. Self-hosted open-source tools can hold both halves. DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail, so the case history shows which named handler opened, worked and documented each incident. Confirm in your own environment that the audit trail records user identity for every task and evidence change, and that handler accounts map to the people named in the designation. A case record cannot prove a designation exists, but it can show whether the named lead and backup were the people actually doing the work.

The designation document belongs in a wiki with version control. XWiki (LGPL-2.1-or-later) keeps every change to a page, recording what changed, when and by whom, and lets reviewers compare any two versions or roll back to an earlier one. That history covers the annual review and any review triggered by a significant enterprise change, which the Safeguard expects. Check that your deployment retains the full history for the designation page, that page history cannot be purged by ordinary editors, and that a dated review note is recorded even when the names do not change, since a review with no change still needs evidence.

Access to the record is the control that keeps it trustworthy. BookStack (MIT) assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. A practical setup places the designation page in a restricted book where only the incident response owner and approvers can edit, while the wider workforce has view access. Confirm the role configuration in your own instance and test it with a non-editor account. These tools support the evidence trail, but they do not make the organization compliant. Designating personnel, overseeing any service provider and deciding who is on call remain management decisions that the organization owns, and the assessment outcome depends on the organization's own documentation and practice.

Where organizations fall short on the incident handling lead

Safeguard 17.1 is short on paper, so most gaps are in the details: who is named, whether the named person can act, and whether the document stays accurate. The cards below cover the failures assessors and incident responders most often find, each with the check that closes it.

A role named without a person

The designation lists a title such as "Head of security" or "incident manager" but no individual, so nobody knows who coordinates a response at 2 a.m. The assessment specification scores the Completeness of the documentation, and a designation that omits the people it covers leaves components missing. Fix it by naming the individual, their role, and how to reach them outside normal working hours.

No named backup

The lead is the only person authorized to manage incident handling, so an absence, resignation or leave stops the process. Safeguard 17.1 calls for at least one backup designated alongside the key person. Check that the backup has the same authority, access to the incident records and the same contact channels as the lead.

A provider with no internal overseer

Many enterprises rely on a managed detection or incident response provider and assume the provider's staff are the designated personnel. Safeguard 17.1 requires at least one internal person to oversee any service provider's work. Confirm that an employee holds that oversight role, can approve provider actions, and receives the provider's incident reports.

A document with no date or owner

A designation memo that carries no issue date, version or approver cannot show when it took effect or who signed it. Assessors look for documentation that identifies the designated personnel, so an undated record weakens the evidence even when the names are correct. Record the approving executive, the effective date and a version number, and keep prior versions under change control.

No annual or change-triggered review

Safeguard 17.1 requires the designation to be reviewed each year and after significant enterprise changes such as a merger, a reorganization or a new managed service contract. Without a review, departed staff remain listed and new providers go unrecorded. Add the review to the annual compliance calendar and to the change management checklist for major organizational events.

Mismatch with on-call and contact records

The designation names one person, while the on-call rota, the paging tool and the incident contact list name another. During an incident responders follow the live record, not the policy document. Compare the designation with the on-call schedule and the contact details used under Safeguard 17.2, then correct whichever record is out of date.

Common questions about Safeguard 17.1 cost, effort and outsourcing

How much effort does it take to name an incident handling lead and backup?

The designation itself is a small task: choose one key person and at least one backup, document the decision, and record their responsibilities for coordinating and documenting response and recovery. The effort sits in what surrounds that document. Leads need time to learn the incident process, keep their contact details current, and take part in exercises and reviews. Ongoing effort recurs because Safeguard 17.1 expects the designation to be reviewed annually or after significant enterprise changes, such as a reorganization, a new service provider or a change in the systems in scope. Ask your team to estimate the hours for the lead and backup separately, including training and time reserved for an active incident, since that is where most of the real demand falls.

Can a managed security provider act as the incident handling lead?

Yes. Safeguard 17.1 allows personnel to be employees, service providers or a mix of both. If a provider holds the role, at least one person inside your organization must oversee the provider's work, so the provider does not operate unchecked. Your internal overseer should understand the escalation path, have authority to make decisions, and receive the provider's documentation after each incident. Confirm in the contract who is on call, response times, what the provider documents and how quickly records reach your team. The designation document should name both the provider's lead and the internal overseer, and it should say which party decides on containment, notification and recovery.

What does the internal team need to provide for this safeguard?

Your internal team needs to provide three things: a named overseer with the authority to supervise incident handling, a documented designation that is kept current, and access to the systems and records the lead will need during an incident. The overseer is responsible for the outcome even when a provider does the work. The team also needs to keep the designation under review, update it after organizational changes, and make sure the lead and backup are included in incident exercises and post-incident reviews. Where these responsibilities sit with people who already hold other roles, confirm that the time allocation is written down and approved by management.

Can an organization designate its incident handling personnel without outside help?

Yes, an organization can designate its own lead and backup without an external partner, and Safeguard 17.1 does not require one. The assessment specification checks for documentation that designates incident handling personnel, and a completeness measure that considers the components included in that documentation. A small internal team can meet this with a short, approved document that names the people, their backups, their responsibilities and the review date. Outside help becomes useful when the internal team lacks people with incident response experience, when the systems involved need technical preparation, or when the team wants a second opinion on the documentation before an assessment.

How long does it take to be ready for an assessment of this safeguard?

The time depends on how much work the organization has already done, not on a fixed period. Readiness is faster when a lead and backup are already named, the designation is written down, contact details are current and the team has run at least one incident exercise. It is slower when roles are informal, when a service provider is involved and its oversight has never been documented, or when the organization must first agree on who holds the role. Ask any partner to base its timeline on a written scope and on a review of your current documentation. Treat any unsupported duration as a warning sign, since readiness depends on the environment, the people involved and the number of systems in scope.

Do the CIS Controls require a certification for this safeguard?

No. The CIS Controls are a set of prioritized safeguards that organizations can use to improve their own cybersecurity, and CIS states that they do not replace any regulatory, compliance or authorization scheme. Safeguard 17.1 is measured against the CIS Controls Assessment Specification, which describes what to measure, but a CIS assessment is not a certification. If a customer or regulator asks for evidence, they may accept your own documentation, an independent assessment or a result tied to another framework. The CIS Controls Navigator maps Safeguard 17.1 to controls in frameworks such as NIST SP 800-53 and ISO/IEC 27001:2022, so confirm with your customer which framework their request actually references.

What can a partner deliver in a fixed-scope engagement for this safeguard?

DeployOpen works on fixed-scope engagements, so scope, deliverables and timelines are agreed in writing before work starts. For Safeguard 17.1, a partner can help prepare the designation document, set up the incident records and communication tools that the lead and backup will use, configure access and audit trails in a self-hosted platform, and prepare the evidence an assessor would review. A partner does not issue audit reports or certificates, and it does not take ownership of the controls. Your organization keeps ownership of the designation and the decisions. Ask for the deliverables in writing, the systems in scope, the internal roles required and how post-engagement support is handled, which can be arranged as a retainer.

What should a quote for this safeguard include?

A useful quote lists each deliverable, the systems and teams in scope, and the roles the client must provide. Ask for the following items to be stated separately: preparation of the designation document, configuration of the self-hosted tools that will hold incident records, evidence preparation, and any training or exercise support. Separate one-time work from recurring work such as annual review, tool upgrades and support retainers. Confirm who signs off on the scope, what happens if the number of systems or service providers changes, and which assumptions the timeline depends on. Your internal team should check that the quote does not assume a designation or decision authority that only your leadership can grant.

How DeployOpen scopes and prepares evidence for Safeguard 17.1

DeployOpen works on Safeguard 17.1 as an implementation partner: we help prepare the designation documentation, the supporting records and the internal oversight arrangements that your organization owns. Designation, staffing decisions and the review cycle stay with your leadership, and only an independent assessor can issue a report on the result.

How we scope

Confirm which incident handling roles exist today, whether staff, a service provider or a hybrid model is in use.
Agree in writing which systems, teams and provider contracts the designation documentation will cover.
Set the review trigger for the annual designation check and for significant enterprise changes, in the fixed-scope agreement.

How we build

Draft the designation record naming the key person and at least one backup, with contact details and their responsibilities.
Document the internal oversight owner for any service provider performing incident handling work.
Test the records against the assessment specification's completeness measure so missing components are found before assessment.

How we hand over

Deliver the designation documentation, oversight records and review schedule in formats your team can maintain.
Walk the key person and backup through the records so they can confirm and update them without outside help.
Confirm with your assessor which evidence they expect to sample before the assessment begins.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer if your team wants help at each annual review.
Re-check the designation after staff changes, provider changes or significant platform changes, as agreed in scope.
Provide a quote based on the written scope, since DeployOpen does not publish a price list.