CIS incident response policy template (Control 17) guide

What a CIS incident response policy template must establish

If a customer, contract or regulator asks for CIS Controls alignment on incident response, the short answer is this: CIS publishes a free IG1 incident response policy template that supports Safeguards 17.1 to 17.3, and IG2 adds Safeguards 17.4 to 17.8, which cover the documented response process, roles, communications and exercises that the template does not address. Control 17 has 9 Safeguards in total: 3 at IG1, 5 added at IG2 and 1 added at IG3. Your policy therefore has two layers. The first layer names one incident handling lead and at least one backup, maintains contact information for the parties that must be told about an incident, and sets a documented process for the workforce to report suspected incidents, including the reporting timeframe, the recipient, the mechanism and the minimum information required.

The organization owns the policy and the controls. Your leadership approves the designations, the contact list and the reporting rules, and your staff carry them out. An implementation partner can help draft the process, set up the reporting channels and assemble the records that show the process runs. Only an independent auditor, assessor or certification body issues a report or certificate on the result. Before you commit to a timeline or scope with anyone, confirm which Implementation Group your customer or regulator expects, because that determines whether the IG2 response process and communication plan are in scope at all. The CIS Controls Assessment Specification for Control 17, linked from the policy templates page, is the place to see how each Safeguard is measured.

The lead designation deserves specific attention. Safeguard 17.1 allows the personnel to be employees, service providers or a hybrid, but if a service provider covers the role, at least one internal person must oversee its work. Record who holds the lead and backup roles, who oversees any outsourced responders, and the date of the annual review or the review triggered by a significant change in the enterprise. Confirm with your legal and communications teams who must be on the contact list before the first incident, since a contact list that is out of date during an event is one of the most common gaps assessors find.

Which Safeguards the IG1 policy must cover

Control 17 has nine Safeguards, but only the first three are IG1 and belong in a baseline incident response policy. Each card below covers one of them, with what the assessment specification checks, so the policy can be written to pass that check rather than to sound complete.

Designate an incident handling lead and backup

Safeguard 17.1 asks for one key person and at least one backup to manage the incident handling process, coordinating and documenting response and recovery. The people can be employees, a service provider or a hybrid of both. If a provider is used, the policy must name an internal person who oversees its work. Write the designation with names or role titles, a deputy for every shift or absence, and a review trigger: the designation is reviewed annually or after significant enterprise changes. The assessment specification checks that the designation exists and is maintained, so an unnamed role or a lapsed review date is the usual gap.

Maintain incident contact information

Safeguard 17.2 asks the enterprise to establish and maintain contact information for the parties that need to be told about security incidents. In practice this list covers internal leaders, legal, privacy, communications, cyber insurers, law enforcement contacts, regulators where a notification duty applies, and key service providers. Record for each contact a name or role, a primary channel, a backup channel and the date it was last verified. The policy should state who owns the list and how often it is checked. Assessors look for a current list that matches the organization's actual notification obligations, not a template copied from another company.

Set the workforce incident reporting process

Safeguard 17.3 asks for a documented enterprise process that tells the workforce how to report security incidents. The process must cover the reporting timeframe, who receives the report, the reporting mechanism and the minimum information a reporter must supply. Staff need a channel that works when the primary system is the thing under attack, such as a phone line or a second mailbox. Define the minimum fields, for example what happened, when it was noticed, which systems are affected and who else knows. The assessment specification checks the process itself and whether it is documented, so the policy must state every element rather than refer to a general reporting habit.

Evidence the assessment specification checks

For each IG1 Safeguard, the CIS Controls Assessment Specification defines inputs, operations and measures that show whether the requirement is implemented. For Control 17 that means a named handling lead and backup, a maintained contact list and a documented reporting process, each with an owner and a review record. Assemble one document set for these three items with version history and approval dates. Ask the internal owner which artifacts they will produce during an assessment, and confirm with your assessor which form of evidence they accept, since CIS describes what to measure but not how to measure it.

What IG2 adds to the incident response policy

The IG1 policy template stops short of the Safeguards that IG2 adds to Control 17, so the organization has to write the IG2 sections itself or have a partner help prepare them. The first of these is Safeguard 17.4, which asks for a documented incident response process that addresses roles and responsibilities, compliance requirements and a communication plan. The process must be reviewed annually or after significant enterprise changes. In practice, this means the policy needs a section that names who decides what during an incident, which legal, regulatory or contractual notification duties apply to the organization, and who speaks to customers, regulators, staff and the press. Decide who owns each of those duties before drafting, because the assessor will look for the named roles, not a general statement that teams will coordinate.

The IG2 additions to Control 17 cover more than the process itself. Safeguards 17.5 to 17.8 extend the Control into areas such as exercises, post-incident review and incident thresholds, and the wording of each is set out in the CIS Controls Assessment Specification for Controls v8.1. Do not rely on a summary for these. Read the exact text of each Safeguard in the CIS Controls Assessment Specification for Controls v8.1 and map each requirement to a section of your policy, a procedure or an evidence record before you draft. A gap found at this stage costs far less to fix than one found during an assessment.

Plan for two kinds of cost and effort. The first is internal: the people who own the compliance, communications and legal duties must review and approve the new sections, and the annual review cycle recurs for as long as the policy stands. The second is external, where an implementation partner drafts the sections, runs tabletop exercises or checks the evidence. Ask any partner to state in writing which sections they will draft, which they will only review, and which evidence the organization must keep. Confirm with your own counsel which notification obligations apply to your sector and jurisdiction, because CIS states that the Controls do not replace regulatory requirements.

Who writes, runs and verifies the incident response policy

The organization owns the incident response policy, the controls it describes and every decision made under them. Safeguard 17.1 asks for one key person and at least one backup to manage the incident handling process, coordinating and documenting response and recovery. That designation is a management decision, and it belongs to the organization even when a service provider does much of the hands-on work. The team also approves the contact list in Safeguard 17.2 and the reporting process in Safeguard 17.3, because those documents tell staff and outside parties who to call and when.

Handling lead and backup: Name both people in writing, with their authority to declare an incident and direct the response.
Contact approval: Confirm that internal and external contacts, including legal, regulators, insurers and key providers, are current and approved by an accountable owner.
Annual review: Schedule the policy and the designation for review each year and after significant changes to the enterprise.
Provider oversight: If a service provider supplies responders, keep at least one internal person responsible for overseeing its work.
Staff awareness: Make sure employees know how to report an incident, to whom and through which channel.

Check that the named lead and backup can be reached outside normal hours and that the designation record shows the date it was last reviewed.

How to take the policy from template to assessable evidence

This sequence turns CIS's IG1 incident response template into a policy your organization has adopted, staffed, tested and reviewed, with dated records an assessor can check against Safeguards 17.1 to 17.4. Each step closes with a named output so you can see what is finished before moving on.

Adapt the IG1 template to your enterprise
Start with CIS's free Incident Response policy template and rewrite it for your organization's scope, systems, business units, service providers and reporting lines. Replace placeholder text with your real names, functions and channels, and remove any clause that does not describe how you operate. The output is a draft policy with a version number, an owner and a list of the Safeguards it is intended to support, so the assessor can trace each clause to a Safeguard.
Designate the incident handling lead and backup
Name one key person and at least one backup to manage the incident handling process, coordinating and documenting response and recovery. Under Safeguard 17.1, these people may be employees, service providers or a hybrid, and if a service provider does the work, an internal person must oversee it. Record the designation in a signed memo or role register with the date, and note that the designation is reviewed annually or after significant enterprise changes. The output is that register, which the assessor will ask to see first.
Build and test the incident contact list
List every party that must be told about a security incident, such as executive decision makers, legal counsel, privacy officers, regulators where a notification duty applies, cyber insurers, key customers, law enforcement contacts and critical service providers. Under Safeguard 17.2, this information must be maintained, so assign an owner and record when each entry was last verified. Test the list by sending a simulated notice to a sample of contacts and log the replies. The output is the dated contact list plus the test record.
Publish the workforce reporting process
Document how employees and contractors report a suspected security incident. Safeguard 17.3 expects the process to set the reporting timeframe, the people or mailbox to report to, the reporting mechanism and the minimum information a reporter must supply. Publish it in the places staff already look, such as the intranet and onboarding material, and include it in security awareness training. The output is the published procedure, the distribution record and a sample report form, which together show the workforce can act on it.
Write the response process, roles and communications (IG2)
If IG2 applies to your enterprise, document the response process as Safeguard 17.4 describes: roles and responsibilities, compliance requirements that apply to your sector and jurisdiction, and a communication plan covering internal, customer, regulator and public messages. Confirm the regulatory clauses with your legal or compliance team rather than relying on the template. The output is a response procedure with a role matrix and communication plan that map to the earlier contact list. If you are only in IG1, record that this step is out of scope and why.
Approve the policy and set the review cycle
Have the accountable executive approve the policy, the lead and backup designation and the response process, and record the approval date and version. Schedule the annual review and add triggers for a review after significant enterprise changes, as Safeguards 17.1 and 17.4 require. Keep the approved versions in a controlled repository so earlier versions remain retrievable. The output is a signed approval record and a review calendar that the assessor can compare against your change history.
Collect dated evidence for the assessor
Gather the artifacts that show each Safeguard is operating, not only written: the approved policy, the role register, the dated contact list, the reporting procedure with its distribution record, the response plan and records of any reviews or exercises. Ask your independent assessor which evidence format and retention period they expect before you start. The output is an evidence index that maps each artifact to a Safeguard and a date, prepared by your team. Assessors and certification bodies issue the findings, so confirm their requirements directly with them.

Evidence that shows each Safeguard is in place

This table pairs each of the four Control 17 Safeguards in the IG1 and IG2 policy scope with the document or record an assessor would ask to see, who should own it and how often it changes. Use it as a checklist before an assessment, and confirm each review cadence against your own governance calendar where the specification does not fix one.

Safeguard	Evidence an assessor expects	Owner and change trigger
17.1 Designate personnel to manage incident handling	A signed designation memo naming one key person and at least one backup, with their responsibilities for coordinating and documenting response and recovery	Executive or security leadership owns the designation. Review annually and after significant enterprise changes, and if a service provider is used, record the internal overseer.
17.2 Maintain contact information for reporting incidents	A contact register listing internal and external parties to inform, with methods of contact and a dated record of the last review	Incident handling lead maintains it. Update when staff, providers, regulators or insurers change, and confirm entries on a set schedule you define and document.
17.3 Enterprise process for workforce incident reporting	A written reporting procedure stating the reporting timeframe, who receives reports, the reporting mechanism and the minimum information required, plus evidence it was communicated to staff	Policy owner publishes it and security awareness owners distribute it. Revise when reporting channels change, and keep acknowledgement or training records as proof of rollout.
17.4 Documented incident response process	An approved response process covering roles and responsibilities, compliance requirements and a communication plan, with a version history showing annual review	Incident handling lead drafts and an accountable executive approves. Review annually and after significant enterprise changes, and retain the signed review record.

Why incident response policies fail assessment

Most CIS incident response policies fail on the same few points: a named person with no backup, contacts nobody has checked, and a reporting process the workforce has never seen. The cards below cover the gaps an assessor is most likely to find, and what to check before the assessment starts.

No named backup handler

Safeguard 17.1 asks for one key person and at least one backup to manage incident handling. A policy that names a single individual, or lists a role with no person behind it, fails on the first leave of absence. Check that both people are named, that each knows the handoff steps, and that the designation is reviewed annually or after significant enterprise changes.

Stale contact lists

Safeguard 17.2 requires contact information for every party that must be told about a security incident. Lists often hold former staff, retired vendor contacts and regulator mailboxes nobody monitors. Ask the policy owner to show the list, the date it was last verified and who verifies it, and test a few entries before the assessor does.

Reporting process the workforce has not seen

Safeguard 17.3 asks for a documented process that tells staff the reporting timeframe, who to report to, the mechanism and the minimum information required. A document stored on a wiki that no one opens does not show the workforce knows the process. Look for evidence of distribution, such as acknowledgments, training content or a test report from a staff member.

Provider handling without an internal overseer

Under Safeguard 17.1, personnel may come from a service provider, but at least one internal person must oversee that provider's work. Many policies name an outsourced SOC or managed response firm and stop there. Confirm the internal overseer is named in the policy, has the authority to direct the provider and receives the provider's incident reports.

IG2 sections missing from IG2 scope

The IG1 policy template covers Safeguards 17.1 to 17.3 only. An organization in scope for IG2 also needs the documented response process, its roles and responsibilities, compliance requirements and a communication plan under Safeguard 17.4, which the IG1 template does not supply. Compare the policy against the full Control 17 list before claiming IG2 coverage.

No record of review after change

Safeguard 17.4 requires the response process to be reviewed annually or after significant enterprise changes. Assessors look for a dated review record, not only a revision number in the header. Keep the approver, the date, the change that triggered any out-of-cycle review and the changes made, so the record survives the next assessment.

Incident response policy questions buyers ask

Is the CIS incident response policy template free to use?

Yes. CIS publishes its policy templates at no charge, and the Incident Response template is one of them. CIS states that the Controls are free for any organization to use to improve its own cybersecurity. The CIS Controls content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, which means commercial use requires CIS's prior approval. Organizations using the template for internal purposes are generally within the free use CIS describes, but the license limits redistribution and derivative works. Confirm the license terms on the CIS Controls Policy Templates page before you repackage the template for clients or sell it as a product. Free text does not complete the work, though. Your organization still has to adapt the template to its own roles, contacts and reporting channels and then approve and run it.

Can a service provider act as the incident handler under Safeguard 17.1?

Yes, a service provider can fill the incident handling role, but the enterprise keeps responsibility for it. Safeguard 17.1 allows the designated personnel to be employees, service providers or a hybrid of both. If a provider is used, at least one internal person must oversee its work. Your policy should name that internal overseer, the provider's responsibilities, and the backup arrangement. The designation must also be reviewed annually or after significant changes, such as a new provider or a major reorganization. Ask the provider to show how it coordinates and documents response and recovery, and check that its contract gives your team access to the records it produces during an incident.

How often must a CIS incident response policy be reviewed?

The documented incident response process under Safeguard 17.4 must be reviewed annually or after significant enterprise changes. Safeguard 17.1 applies the same pattern to the designation of the incident handling personnel. Annual review is the floor, not the trigger for every update. Treat a new cloud platform, a merger, a change in regulated data, a new outsourced SOC, or a real incident that exposed a gap as events that require an earlier review. Record each review with a date, the reviewer, and the changes made. Assessors look for that trail as much as for the document itself.

Is IG1 enough for incident response, or do I need IG2?

IG1 covers the baseline, but many regulated organizations need the IG2 Safeguards too. The IG1 policy template addresses Safeguards 17.1 to 17.3: a designated handling lead and backup, contact information for parties that must be informed, and a workforce reporting process. IG2 adds 17.4 to 17.8, which cover the documented response process with roles, compliance requirements and a communication plan, along with exercises, post-incident reviews and incident thresholds. Under CIS's definitions, IG2 applies to enterprises with more operational complexity that often hold sensitive information. Choose your Implementation Group based on your own complexity and data sensitivity, and confirm the contractual or regulatory requirements that apply to you, because CIS states the Controls do not replace any regulatory or compliance scheme.

What evidence does an assessor expect for CIS Control 17?

The assessor looks for documents that exist, are current, and show use. For Control 17, expect to show the named incident handling lead and backup with their designation date and review record, the current contact list for parties that must be informed, and the written workforce reporting process with its timeframe, reporting route and minimum information. For IG2, add the documented response process, the role assignments, the communication plan, and records of exercises and post-incident reviews. The Assessment Specification describes what to measure for each Safeguard, so review its Control 17 section before you collect evidence. Ask your assessor which artifacts they accept, such as ticket exports, tabletop reports or signed approvals, and in what format.

Can an outside partner write the incident response policy for us?

Yes, an outside partner can draft the policy and prepare the supporting material, but your organization must own and approve it. The partner can adapt the CIS template to your environment, build the contact list structure, design the reporting path, and set up exercises. Your leadership still has to name the incident handling lead, accept the risks, and sign the policy. A partner that prepares systems and evidence does not issue audit reports or certifications. Only an independent assessor or certification body does that. DeployOpen works on fixed scope agreed in writing before work starts, so ask any provider to define the policy deliverables, the staff who must sign off, and what the handover includes before work begins.

How DeployOpen prepares incident response evidence

DeployOpen works on CIS Control 17 as an implementation partner: we help your team set up the people, contact lists, reporting path and response process that the policy describes, and we prepare the records that show they operate. Your organization owns the policy, its approval and every incident decision, and only an independent assessor can judge the result.

How we scope

Confirm which Implementation Group applies and which Control 17 Safeguards fall inside that group
Agree in writing which systems, teams and service providers the incident response policy covers
Name the deliverables, such as the policy, contact list, reporting process and response runbook, before work starts

How we build

Draft the policy text around the designated incident handling lead and backup, with review triggers stated
Set up the contact information register and the workforce reporting channel in your own environment
Test the documented response process with a tabletop exercise and record the findings for remediation

How we hand over

Deliver the documents, configuration notes and evidence folder so your staff can maintain them without us
Map each Safeguard to the evidence that shows it operates, using the assessment specification as the reference
Walk your designated personnel through the runbook and record who approved each version

How we support

Ongoing support, updates and exercises are available as a retainer after the fixed-scope work closes
Revisit the policy and contact list when the annual review or a significant enterprise change requires it
Confirm with your independent assessor which evidence formats and review records they expect before the assessment

CIS incident response policy template (Control 17)