Small teams that adopt CIS Controls Implementation Group 1 usually know which 56 Safeguards are in scope but not which to do first, who owns each one, or what "done" looks like on day 90. This template is a sequenced rollout plan you can adopt as written: three 30-day phases, an owner and evidence for every IG1 Safeguard in CIS Controls v8.1, decision points, and a weekly reporting rhythm. CIS describes IG1 as essential cyber hygiene, the minimum standard for every enterprise, and says it typically fits small to medium organisations with limited IT and security expertise. The plan is written for an IT manager, a managed service provider or a part-time security lead. For the background on the Controls, Implementation Groups and Benchmarks, see the CIS Controls Guide; this page is the delivery plan.
How to use this template
- Replace text in square brackets, such as [Organisation], [IT lead] and [MSP], with your own names. Dates and durations are NHI Mgmt Group's recommended sequence, not CIS requirements. CIS sets the Safeguards and some intervals; the 90-day order is ours.
- Where a Safeguard states a period, such as 45 days for dormant accounts or weekly backups, the period comes from the CIS Controls Assessment Specification for v8.1. Keep those values unless you document a reason.
- "Must" marks a step needed to claim the Safeguard; "should" marks a recommended practice.
- Track status per Safeguard as Not started, In progress, Implemented or Implemented with evidence. Only the last counts in reporting.
- Ninety days is achievable for a single-site organisation of up to a few hundred devices with an identity provider and device management already licensed. Larger or multi-site estates should stretch each phase to 45 or 60 days and keep the order.
1. Purpose
1.1 This plan sets out how [Organisation] will implement the 56 Safeguards of CIS Controls v8.1 Implementation Group 1 by [target date], with evidence for each, so that [Organisation] meets a recognised minimum standard of cyber hygiene and defends against common, non-targeted attacks.
1.2 The plan supports [list obligations, for example a customer security questionnaire, cyber insurance renewal, or alignment to NIST CSF 2.0].
2. Scope and roles
2.1 Scope covers all enterprise assets: end-user devices, servers, network devices, cloud tenants and SaaS applications holding [Organisation] data, and all user, administrator and service accounts.
2.2 Roles:
| Role | Named person | Responsibilities |
|---|---|---|
| Sponsor | [Managing director or COO] | Approves the plan, budget and exceptions; receives the fortnightly report |
| Plan owner | [IT lead] | Runs the plan, owns the tracker and evidence register |
| Technical delivery | [IT team or MSP] | Configures tools and collects evidence |
| Data owners | [Department heads] | Confirm data inventory, retention and access lists (Control 3) |
| Incident lead and deputy | [Name], [Name] | Safeguard 17.1: one key person and at least one backup |
2.3 Where an MSP delivers Safeguards, [Organisation] must keep an internal owner for each, and the MSP must supply the evidence listed in section 6. See Choosing an IT Support Provider or MSP Securely.
3. Phase 1, days 1 to 30: know what you have and lock the front doors
3.1 Phase 1 builds the inventories every later Safeguard depends on and closes the access paths most used in non-targeted attacks.
| Safeguard | Action in this plan | Evidence |
|---|---|---|
| 1.1 Establish and Maintain Detailed Enterprise Asset Inventory | Export devices from device management, directory and network; merge into one inventory with owner and location | Inventory with last-updated date |
| 1.2 Address Unauthorized Assets | Weekly check of unknown devices; remove, deny or quarantine | Unknown asset log with action taken |
| 2.1 Establish and Maintain a Software Inventory | Export installed software from device management; record business purpose | Software list with review date |
| 2.2 Ensure Authorized Software is Currently Supported | Flag unsupported titles; plan replacement or record an exception | Support status column and exceptions |
| 2.3 Address Unauthorized Software | Remove or document exceptions monthly | Removal tickets |
| 5.1 Establish and Maintain an Inventory of Accounts | List user, administrator and service accounts across directory, cloud and SaaS | Account inventory; quarterly validation scheduled |
| 5.2 Use Unique Passwords | Enforce a password manager; local admin passwords unique per device | Policy settings and coverage report |
| 5.3 Disable Dormant Accounts | Disable accounts inactive for 45 days, where supported | Dormancy report and disable log |
| 5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts | Create separate admin accounts; remove admin rights from daily accounts | Admin list mapped to people |
| 6.1 Establish an Access Granting Process | Ticket with approver for every new access | Process document and sample tickets |
| 6.2 Establish an Access Revoking Process | Leaver checklist triggered by HR; disable on the last day | Leaver list reconciled with disabled accounts |
| 6.3 Require MFA for Externally-Exposed Applications | Enforce MFA in the identity provider for email and all internet-facing SaaS | Policy export and exception list |
| 6.4 Require MFA for Remote Network Access | MFA on VPN and remote desktop gateways | Gateway configuration |
| 6.5 Require MFA for Administrative Access | MFA on all admin accounts, including cloud consoles and break-glass | Admin MFA report |
| 4.7 Manage Default Accounts on Enterprise Assets and Software | Disable or make unusable vendor default accounts such as root and administrator | Default account register by platform |
3.2 MFA rollout must run in report-only or audit mode for at least five working days before enforcement, then roll out by group, starting with IT and administrators. Rollback is by moving a group back to report-only, never by disabling the policy for everyone.
3.3 Gate to phase 2: inventories exist with owners, MFA is enforced for administrators and remote access, and no dormant account older than 45 days remains enabled.
3.4 Phase 1 addresses the most common entry point we see in breach analysis: a password that works on its own on an internet-facing service. Change Healthcare's remote access portal accepted a stolen password without MFA; see the Change Healthcare Breach 2024.
4. Phase 2, days 31 to 60: harden, patch and filter
| Safeguard | Action in this plan | Evidence |
|---|---|---|
| 4.1 Establish and Maintain a Secure Configuration Process | Adopt CIS Benchmark Level 1 or vendor baselines for each platform; review annually | Configuration standard with review date |
| 4.2 Establish and Maintain a Secure Configuration Process for Network Infrastructure | Same for firewalls, switches and wireless | Network configuration standard |
| 4.3 Configure Automatic Session Locking on Enterprise Assets | 15 minutes or less for general-purpose operating systems; 2 minutes or less on mobile devices | Policy export and compliance report |
| 4.4 Implement and Manage a Firewall on Servers | Enable operating system or virtual firewalls | Firewall status report |
| 4.5 Implement and Manage a Firewall on End-User Devices | Host firewall with default deny for inbound | Policy export |
| 4.6 Securely Manage Enterprise Assets and Software | Manage over SSH and HTTPS; disable Telnet and HTTP management | Scan showing insecure management disabled |
| 7.1 Establish and Maintain a Vulnerability Management Process | Write the process; review annually | Process document |
| 7.2 Establish and Maintain a Remediation Process | Risk-based remediation timelines; review monthly or more often | Monthly review record |
| 7.3 Perform Automated Operating System Patch Management | Automatic OS updates, monthly or more often | Patch compliance by OS version |
| 7.4 Perform Automated Application Patch Management | Automatic application updates, monthly or more often | Application patch report |
| 9.1 Ensure Use of Only Fully Supported Browsers and Email Clients | Managed, auto-updating browsers and mail clients only | Software inventory filter |
| 9.2 Use DNS Filtering Services | Protective DNS on all devices, including off network | DNS filtering coverage |
| 10.1 Deploy and Maintain Anti-Malware Software | Anti-malware on all supported assets | Agent coverage against inventory |
| 10.2 Configure Automatic Anti-Malware Signature Updates | Automatic updates on | Update status report |
| 10.3 Disable Autorun and Autoplay for Removable Media | Group policy or device management setting | Policy export |
| 12.1 Ensure Network Infrastructure is Up-to-Date | Current, supported firmware on network devices | Firmware versions against vendor support |
4.1 Configuration changes must be piloted on [5 to 10] devices for one week before wide rollout, with a documented rollback (removing the device from the policy group).
4.2 Gate to phase 3: patch compliance at or above [95]% for supported devices, anti-malware and DNS filtering on every device in the inventory.
4.3 See the Patch Management Guide and the Endpoint Hardening Checklist.
5. Phase 3, days 61 to 90: recover, log, protect data and prepare to respond
| Safeguard | Action in this plan | Evidence |
|---|---|---|
| 11.1 Establish and Maintain a Data Recovery Process | Write recovery scope, priorities and backup security; review annually | Process document |
| 11.2 Perform Automated Backups | Automated backups weekly or more often, by data sensitivity | Backup job report |
| 11.3 Protect Recovery Data | Encrypt backups; separate backup credentials from production admin | Backup configuration |
| 11.4 Establish and Maintain an Isolated Instance of Recovery Data | Offline, immutable cloud or off-site copy | Isolation configuration |
| 8.1 Establish and Maintain an Audit Log Management Process | Define what is logged, retained and reviewed; review annually | Process document |
| 8.2 Collect Audit Logs | Enable logging on assets, identity provider and key SaaS | Log source list |
| 8.3 Ensure Adequate Audit Log Storage | Size storage for the retention you set | Storage and retention settings |
| 3.1 Establish and Maintain a Data Management Process | Write how sensitive data is handled, owned and disposed of | Process document |
| 3.2 Establish and Maintain a Data Inventory | List sensitive data sets and where they live | Data inventory |
| 3.3 Configure Data Access Control Lists | Restrict shares and SaaS folders to need to know | Access list exports |
| 3.4 Enforce Data Retention | Apply retention periods to the inventory | Retention settings |
| 3.5 Securely Dispose of Data | Disposal method per media type | Disposal records |
| 3.6 Encrypt Data on End-User Devices | Full-disk encryption on laptops and mobiles | Encryption compliance report |
| 14.1 to 14.8 Security awareness | Programme covering social engineering, authentication, data handling, unintentional exposure, incident reporting, missing updates and insecure networks | Training records and completion rates |
| 15.1 Establish and Maintain an Inventory of Service Providers | List providers with classification and an internal contact | Provider inventory |
| 17.1 Designate Personnel to Manage Incident Handling | Name the lead and backup | Named roles |
| 17.2 Establish and Maintain Contact Information for Reporting Security Incidents | Contacts for staff, MSP, insurer, police and regulator | Contact list with review date |
| 17.3 Establish and Maintain an Enterprise Process for Reporting Incidents | How, to whom and how fast staff report | Published process |
5.1 A restore test must be completed before day 90 even though recovery testing (Safeguard 11.5) sits in IG2; an untested backup is not evidence of recovery.
5.2 In the UK, the incident contact list in 17.2 should include Report Fraud (reportfraud.police.uk, 0300 123 2040), which replaced Action Fraud on 4 December 2025; in Scotland, report to Police Scotland on 101.
5.3 See the Backup Security and Immutable Backup Guide and the Incident Response Plan Template.
6. Evidence register and reporting
6.1 The plan owner must keep one evidence register with, per Safeguard: status, owner, evidence location, date collected and next review date.
6.2 Report to the sponsor every two weeks with five figures:
- Safeguards implemented with evidence, out of 56.
- Share of inventoried devices with patching, anti-malware and encryption in compliance.
- Accounts with MFA enforced, out of accounts in scope.
- Enabled accounts inactive for more than 45 days.
- Days since the last successful restore test.
6.3 Recurring intervals after day 90: account validation at least quarterly (5.1), remediation review monthly (7.2), process documents reviewed annually (4.1, 7.1, 8.1, 11.1, 15.1).
7. Exceptions
7.1 Any Safeguard that cannot be met must have a written exception with the reason, the compensating measure, an owner and an expiry no later than [6 months]. The sponsor approves exceptions.
7.2 Common acceptable exceptions: a legacy device that cannot run anti-malware (isolate it on its own network segment); a SaaS application without MFA support (restrict access to it and plan replacement).
8. Review and approval
8.1 This plan is approved by [Sponsor] on [date] and reviewed at day 30, day 60 and day 90, then annually as part of the security programme.
8.2 After IG1 is complete, [Organisation] will assess IG2 Safeguards that address its specific risks, starting with recovery testing (11.5), service account inventory (5.5) and centralised logging (8.9).
Implementation guidance
- Order matters more than speed. Inventories (Controls 1, 2 and 5) come first because patching, anti-malware coverage and access reviews are measured against them. A Safeguard measured against an incomplete inventory overstates coverage.
- Use what you already licence. Most IG1 Safeguards are settings in an existing identity provider, device management platform, operating system or backup tool. Budget is usually needed only for a backup isolation target, DNS filtering and a password manager.
- Service accounts count. Safeguard 5.1 includes service accounts in the inventory even though the dedicated service account inventory (5.5) is IG2. Record an owner for each now; it makes 5.3 dormancy checks and 6.2 revocation possible. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide.
- Measure with the assessment specification. The CIS Controls Assessment Specification describes the inputs and measures for each Safeguard; use it to decide when a Safeguard is "implemented with evidence".
- Map once. IG1 outcomes line up with NIST CSF 2.0 subcategories such as PR.AA-03 (authentication), ID.AM-01 (hardware inventory), PR.PS-02 (software maintenance) and PR.DS-11 (backups). CISA's Cross-Sector Cybersecurity Performance Goals cover much of the same ground, including asset inventory (1.A), changing default passwords (2.A), revoking credentials for departing employees (2.D) and phishing-resistant MFA (2.H). For UK organisations, see the Cyber Essentials Guide.
- Common failure patterns. MFA on email but not on VPN or cloud consoles; backups reachable with the same admin account as production; dormant account checks run on the directory but not on SaaS; anti-malware coverage reported against the tool's own device list instead of the inventory.
Related NHI Mgmt Group resources: CIS Controls Guide · CIS Control 5 Account Management Guide · CIS Control 6 Access Control Management Guide · Small Business Cyber Security Checklist · IT Asset Inventory Template