What CIS Controls IG2 adds beyond IG1 for an enterprise
A customer, contract or regulator now asks for CIS Controls IG2, which adds 74 Safeguards to the 56 in IG1, for 130 in total. The additions are concentrated in a few Controls, most visibly Control 8 (audit log management), Control 12 (network infrastructure management), Control 13 (network monitoring and defense), Control 16 (application software security) and Control 18 (penetration testing). Start by reading the request closely: confirm whether it names IG2 as the target or asks for a set of Safeguards, and ask which assessment evidence the requester will accept.
The organization owns its controls. An implementation partner such as DeployOpen can prepare systems, configurations, logging pipelines and evidence, but only an independent auditor or assessor issues any report or attestation. Keep those roles written into the engagement from the start so the scope, owner and sign-off for each Safeguard are clear before any work begins. Where the requester wants a formal assessment, confirm in advance who will perform it and whether that assessor accepts the CIS Controls Assessment Specification as the basis for testing.
Whether IG2 is the right answer depends on the enterprise's complexity, the sensitivity of the data it holds and the security staff it can keep in-house. CIS describes an IG2 enterprise as one with staff who manage and protect IT infrastructure, several departments with different risk profiles, sensitive client or enterprise data, and some Safeguards that need enterprise-grade technology and specialized expertise. Read the full profile on the CIS Implementation Group 2 page and compare it with your own environment before committing to scope.
Where the 74 IG2 Safeguards land, Control by Control
Control 8 is where IG2 expands logging most visibly. It asks the enterprise to decide what gets recorded, collect and keep those records, and review them so that an incident can be reconstructed afterward. IG1 covers 3 of its 12 Safeguards, IG2 adds 8 more, and 1 more applies only at IG3.
- Wider coverage: IG2 moves past a minimal logging baseline toward detailed event records from servers, applications and network devices.
- Central collection: logs are gathered into a store the enterprise controls, so investigators do not depend on each system's local files.
- Time synchronization: consistent clocks let events from different sources be lined up during an investigation.
- Defined retention and review: someone must act on logs, and the retention period must be written down and followed.
- Service provider logs: records from outsourced platforms enter the same review process as internal ones.
Check which log sources are collected today, and ask for a dated review record for at least one of them, since assessors look for proof that logs are read.
Controls 12 and 13 together describe how IG2 moves from managing network devices to watching and defending the network. Control 12 has 1 Safeguard in IG1 and adds 6 at IG2. Control 13 has none in IG1, adds 6 at IG2 and 5 more at IG3, so IG2 is where its requirements first apply.
- Device currency: network devices, firmware and management interfaces are kept patched and on supported versions.
- Documented architecture: current network diagrams and an inventory of how segments connect support both secure design and audit evidence.
- Secure administration: administrative access to network devices uses centralized authentication, encrypted protocols and controlled admin workstations.
- Centralized alerting: network and host intrusion detection signals feed a place where someone reviews and responds to them.
- Segment filtering and flow logs: traffic between segments is filtered, and flow records are kept so unusual movement can be found.
Before engaging a partner, confirm whether network diagrams are current and who owns alert triage, because both are common gaps that assessors test first.
Control 16 is the largest IG2 addition in this group. It covers the life cycle of software the enterprise builds, hosts or buys, and it adds 11 Safeguards at IG2 with 3 more at IG3. Control 18 adds 3 Safeguards at IG2 and 2 at IG3, and it moves penetration testing from an occasional exercise to a managed program. Neither Control has any Safeguard in IG1.
- Secure development process: a written process for designing, reviewing and releasing software, with security checks built into it.
- Third-party component handling: libraries and external code are tracked, and known vulnerabilities in them are triaged.
- Environment separation and developer training: development, test and production are kept apart, and developers receive security training suited to their work.
- Code checks: automated analysis runs against the code before release.
- Penetration testing program: external and internal tests are scoped, performed and followed by tracked remediation and retesting.
When scoping a test, ask the tester for the report format and the retest process, since the evidence an assessor reads is the remediation record, not the test alone.
Control 15 covers providers that hold sensitive data or run critical IT platforms or processes. It has 1 Safeguard in IG1, adds 3 at IG2 and 3 more at IG3. IG2 is where the enterprise must move from knowing its providers to assessing and monitoring them against defined requirements.
- Provider inventory and classification: every provider is recorded with the data or services it touches, so the higher-risk relationships receive more scrutiny.
- Contract security requirements: agreements set out security obligations, incident notice expectations and audit rights.
- Periodic assessment: providers are reviewed against those requirements, using evidence such as reports or questionnaires that the enterprise can check.
- Ongoing monitoring: changes in a provider's posture, incidents or services are tracked between assessments.
- Secure offboarding: when a provider relationship ends, data return or deletion and access removal are confirmed.
A useful first check is whether the provider list matches what finance and procurement actually pay for, because undocumented providers are the usual reason this Control fails.
Control 9 addresses the email and web attack surface. IG1 covers 2 of its 7 Safeguards, IG2 adds 4 more, and 1 more applies only at IG3. The IG2 additions extend protection from supported software and basic filtering into controls over how mail is authenticated, how web traffic is filtered and which file types and extensions are allowed.
- Filtering of DNS and URLs: requests to known malicious or unapproved sites are blocked before a user reaches them.
- Email authentication: DMARC policy is set and enforced so spoofed messages from the enterprise's domain can be rejected.
- Extension control: browser and email extensions are limited to an approved list and reviewed on a schedule.
- File type blocking: file types that commonly carry malware are blocked or quarantined at the mail gateway.
- Anti-malware on mail servers: attachments and links are scanned by the email server before delivery.
Confirm that the DMARC record is published and that its policy is not still in monitor-only mode, because assessors check the live setting and the reporting that backs it.
Why audit logging is the first big jump at IG2
Control 8, Audit log management, more than doubles at IG2. Three of its twelve Safeguards apply from IG1, and IG2 adds eight more, so an IG2 enterprise carries eleven. The IG1 work mostly asks for a written log management process and basic log collection. IG2 moves the program toward centralization, retention, review and logs from service providers. The IG3 enterprise then adds one final Safeguard to the Control.
The practical consequence is that the organization must know its log sources before it can manage them. Build an inventory of every system that produces security-relevant events, including servers, endpoints, cloud accounts, firewalls, identity providers and SaaS platforms that hold sensitive data. Confirm that each source uses synchronized time, because events from different systems cannot be correlated reliably without it. Then decide where logs are collected, how long they are kept under policy and who reviews them, and how alerts reach a responder. Ask each system owner which sources are not yet logging.
An assessor tests this Control by looking for records, not intentions. The CIS Controls Assessment Specification for Control 8 defines the inputs, operations and measures used to verify each Safeguard, so read it before scoping evidence. Expect requests for the log management procedure, configuration exports showing time sources and retention settings, samples of centralized events and records of reviews. A self-hosted open-source log platform can run this collection and retention inside your own environment, but confirm its retention, access control and review features against the Safeguards before you rely on it. Your organization owns the Control, and an independent assessor decides whether the evidence is sufficient.
How network, monitoring and application security change at IG2
IG2 adds Safeguards in the controls that decide whether an enterprise can see, contain and test its own network and software. The four cards below cover the areas where IG2 moves from basic hygiene to managed infrastructure, and each names the record an assessor will ask to see.
Network architecture and management
Control 12 adds Safeguards for secure network architecture, centralized authentication, authorization and accounting (AAA), secure management protocols and maintained network diagrams. IG1 asks only for patch currency on network devices, so IG2 is where the enterprise must show how traffic is segmented and who can administer each device. Check that current diagrams exist, that device administration runs over encrypted, centrally authenticated channels, and that the diagrams match the live environment. Evidence: dated diagrams, AAA configuration exports and an administrative access log.
Centralized alerting and intrusion defense
Control 13 is almost entirely an IG2 concern: none of its Safeguards appear in IG1, and six are added at IG2. These cover centralized security alerting, host-based and network-based intrusion detection and prevention, and filtering between network segments. The practical question is whether alerts reach a person who acts on them within a defined process. Evidence includes detection tool configurations, a sample of triaged alerts with dispositions, and records showing that tuning decisions were reviewed.
Secure development and third-party components
Control 16 has 11 Safeguards at IG2, the largest jump of any Control for in-house or acquired software. They cover a documented secure development process, tracking of third-party components, separation of development, testing and production environments, and code review. IG2 enterprises that build software should expect an assessor to trace a sample release back through its code checks, dependency inventory and environment promotion records. Missing dependency inventories are the most common gap to close first.
Penetration testing and remediation
Control 18 adds Safeguards for external and internal penetration testing at IG2, and the testing must lead to tracked remediation. An assessor looks for a documented testing program, a defined scope and cadence, and proof that findings were fixed or formally accepted and then retested. Confirm with any tester in advance whether the report will map findings to Safeguards and whether the scope covers the environments the enterprise actually runs. Evidence: scope statements, the test report, a remediation tracker and retest results.
Service provider oversight
Control 15 adds Safeguards at IG2 for assessing service providers that hold sensitive data or run critical platforms. The enterprise needs a current provider inventory, classification of each provider by data sensitivity and criticality, contract security requirements, periodic assessment and a defined process for secure decommissioning. Start by listing every provider that touches sensitive client data, then confirm each contract states the security obligations the enterprise will need to verify. Evidence: the provider register, completed assessments and signed contract clauses.
Is your enterprise the kind IG2 is written for?
IG2 is written for an enterprise with more operational complexity than a small business, and CIS describes that enterprise in four traits you can test against your own organization. First, it has staff responsible for managing and protecting IT infrastructure, meaning someone other than a single generalist owns the network, endpoints and identity systems. Second, it has multiple departments with different risk profiles, such as finance, engineering and customer operations, each handling different data and exposed to different threats. Third, it holds sensitive client or enterprise data. Fourth, some of its Safeguards need enterprise-grade technology and specialized expertise. If most of these traits describe you, IG2 is the group your program should be planned against, even if you are not sure how to staff it yet.
Work through the traits with a short written check. List the departments that touch customer or financial records, identify who administers firewalls, directories and cloud accounts, and note where your sensitive data actually lives. Then decide whether you can run log retention, network monitoring and application testing with the people you have. Be careful with the last two points: a single trait is often enough to matter. Do not treat headcount or revenue as the test, because CIS defines the group by function and data sensitivity, not by size.
An organization that only meets the IG1 profile can still need IG2 because of a contract. A customer questionnaire, a procurement clause or a regulator's expectation may ask you to show controls that IG1 does not cover, such as audit log management, network monitoring or penetration testing. Check the wording of each contract and each regulatory requirement you are subject to, and ask the requesting party which CIS Implementation Group or which specific Safeguards they expect. Record the answer. It turns an open-ended demand into a scoped list of Safeguards, which is the input any implementation partner or assessor will need before quoting or testing.
What IG2 demands in staff and tooling
The sequence below turns the 74 IG2 additions into named owners, written processes, centralized logs and a repeatable testing and remediation cycle. Each step ends with an output you can show an assessor, and the staffing split between in-house teams and outside specialists is your decision to make.
Assign a named owner to each Control
Start by naming one accountable owner for each of the Controls that IG2 extends, including Control 8 (audit log management), Control 9 (email and web browser protections), Control 12 (network infrastructure management), Control 13 (network monitoring and defense), Control 15 (service provider management), Control 16 (application software security) and Control 18 (penetration testing). Owners should have authority to fund and approve work, and some owners will share staff across Controls. The output is a signed owner list with backup names and the Safeguards each person answers for. Confirm the list with leadership before any tooling is bought, because every later step depends on someone being accountable for it.
Write the processes IG2 requires
Many IG2 Safeguards are tested as much on documentation as on configuration. Write the processes for log management, network device management, service provider assessment, application security and penetration test remediation, using the Safeguard wording and the assessment specification as your checklist. Keep each document short enough that staff will use it, and record a review date and an approver on every page. The output is a versioned set of processes that the named owners have read and accepted. An assessor will ask to see the approved version and evidence that people follow it, so a document nobody uses will not pass.
Centralize audit logging with defined retention
Route logs from endpoints, servers, network devices, cloud services and critical applications to one log platform, and synchronize clocks across all of them. Set collection rules for detailed, DNS, URL and command-line logs where your Control 8 Safeguards call for them, and set retention periods that your written log management process states and your legal or contractual obligations support. Confirm the retention period with your compliance lead rather than copying a default. The output is a log platform inventory, a retention configuration export and a sample query that shows events from several sources on one timeline.
Build monitoring and alerting on network and email traffic
Using the centralized logs, configure alerting for network intrusion detection, host intrusion detection, DNS and URL filtering, and email authentication and anti-malware events that Control 9 and Control 13 describe. Tune alert thresholds in a test period, record which alerts are triaged and by whom, and document how alert tuning decisions are approved. Open-source sensors and SIEM components can cover parts of this work, but you must confirm each capability against the Safeguard wording before relying on it. The output is a list of active detection rules, a triage record for a sample of alerts and a tuning log.
Add application and network security testing
For internally developed or hosted applications, add secure development steps, dependency checks and code scanning to the delivery pipeline, and extend network testing to the infrastructure and remote access points covered by Control 12 and Control 16. Record which applications are in scope, which test types run against each, and who reviews findings. The output is a pipeline configuration export, a scan schedule and at least one set of findings with an owner and a status for each item. Expect specialist skills here, and decide which of these tests your staff run and which an outside tester performs.
Run penetration tests and a documented remediation cycle
Plan penetration tests for the external and internal environment and for in-scope applications, covering the Control 18 Safeguards. The testers' scope, rules of engagement and reporting format should be agreed in writing before testing starts. When results arrive, log each finding, assign it to an owner, track it to closure and retest the fixed items to confirm the weakness is gone. The output is a signed test scope, the final reports and a remediation register that shows opened, fixed and retested dates for each finding. Whether testing is done by staff, by an outside firm or by a mix is a decision for you, and the register is what an assessor will examine.
Review service providers and confirm readiness
Close the sequence by applying the Control 15 processes to the service providers that hold your sensitive data or run critical platforms. Inventory each provider, classify it, record the security requirements in its contract and review its evidence on a schedule your policy sets. Then run an internal review of the whole sequence against the IG2 Safeguards, marking each one with its owner, process, tool and most recent evidence. The output is a provider register, a completed IG2 gap list with an owner for each open item and a short statement from leadership on what remains. Ask any outside assessor or consultant to show their method and what they will ask you to produce before you commit.
Which IG2 work to keep in-house and which to outsource
This table compares three ways to deliver IG2 work: an in-house build, outsourced implementation with an internal owner, and outsourced testing. Read each row as a work area, then check who usually owns it and what must be confirmed in writing before work starts. The main takeaway is that the organization keeps ownership of its controls and processes, while implementation and independent testing are the parts most often bought in.
| Work area | Who usually owns it | When outsourcing fits | What to confirm in writing |
|---|---|---|---|
| Audit log management (Control 8, IG2 Safeguards 8.2 to 8.9) | Internal security operations owns the log policy and review; platform team runs collection | Collection, centralization and retention build-out when internal staff lack log platform experience | Which log sources are in scope, retention periods, time sync method, and who reviews alerts |
| Network infrastructure management (Control 12, IG2 Safeguards 12.2 to 12.7) | Network team owns architecture, device standards and secure management | Writing secure architecture diagrams and hardening baselines for devices the team has not run before | Device inventory covered, diagram ownership, update cadence, and handover of baseline documents |
| Network monitoring and defense (Control 13, IG2 Safeguards 13.1 to 13.6) | Security operations owns alert handling and tuning; the organization owns detection decisions | Deploying intrusion detection, segment filtering and flow logging when enterprise-grade tooling is new | Sensors and tools delivered, alert tuning ownership, and who responds to alerts after handover |
| Application software security (Control 16, IG2 Safeguards 16.1 to 16.11) | Engineering leadership owns the secure development process; AppSec owns standards | Setting up a secure development life cycle, code checks and third-party component tracking for the first time | Scope of applications, tools installed, developer training content, and who triages findings |
| Penetration testing (Control 18, IG2 Safeguards 18.1 to 18.3) | Internal owner sets scope and tracks remediation; the tester performs the test | Independent external and internal tests that need a qualified tester with no stake in the results | Tester qualifications, rules of engagement, report format, retest scope, and who validates fixes |
| Service provider management (Control 15, IG2 Safeguards 15.2 to 15.4) | Procurement and risk owns provider classification and contract terms | Assessing many providers against security requirements when the organization lacks assessment capacity | Provider classification criteria, assessment questionnaire ownership, and contract clauses the organization must approve |
| Policies, risk decisions and asset ownership | Executive leadership and the CISO own these and cannot be delegated | Drafting supporting documents only, with internal approval before adoption | Who signs each policy, review frequency, and which decisions remain internal |
Questions buyers ask about IG2 Safeguards
Does IG2 include everything in IG1?
Yes. IG2 adds 74 Safeguards to the 56 Safeguards in IG1, for a total of 130 Safeguards at IG2. An enterprise that claims IG2 is expected to implement the IG1 Safeguards first and then the additional IG2 Safeguards, so there is no IG2 shortcut that skips the essential cyber hygiene baseline. The practical consequence is that the IG1 work, including the written processes CIS expects, becomes the foundation that IG2 builds on. Before scoping IG2, confirm which IG1 Safeguards are already implemented and documented, because gaps there will surface as gaps in IG2 as well. The official CIS Implementation Groups page lists the structure for each group.
Is IG2 a certification I can get?
No. CIS Controls are a set of prioritized security practices, not a certification or an audit scheme. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. An organization can implement IG2 and still need a separate attestation, certificate or regulatory assessment if a contract or regulator requires one. Only an independent auditor, assessor or certification body can issue a report or certificate for such a scheme. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Ask any auditor you engage which framework their report covers, and map the IG2 Safeguards to that framework before you assume one covers the other.
How much effort does IG2 take?
The effort depends on scope, and no fixed duration applies to every enterprise. The main drivers are the number of systems and cloud accounts in scope, how many departments hold different risk profiles, how much sensitive client or enterprise data the environment handles, and how many Safeguards already exist in working form. IG2 Safeguards cover audit logging across Control 8, network infrastructure and monitoring across Controls 12 and 13, application security and penetration testing across Controls 16 and 18, and service provider management under Control 15. Each area needs configuration, process documentation and evidence collection, so an enterprise with mature IG1 controls will move faster than one starting from undocumented practices. Ask any provider for a written scope that lists the Safeguards, systems and deliverables before agreeing to a timeline.
Can our own team implement IG2 without outside help?
Often yes, if your staff already have the skills for the technical work and the time to document it. The IG2 Safeguards require enterprise-grade technology and specialized expertise, according to CIS's description of the IG2 enterprise, so the question is whether your team can configure centralized logging, network monitoring, application security testing and penetration testing without gaps. Two decisions should stay in writing whatever you choose: who owns each Safeguard, and how testing is scoped, approved and acted on. Outside help can cover the configuration, the evidence and the testing, but the organization keeps ownership of its controls. Make a skills inventory against the Safeguard list before deciding, and treat any area where the skills are missing as a scoped engagement rather than an assumption.
What does IG2 need from leadership?
IG2 needs named owners, a budget for tooling and staff time, and a decision on how far the program reaches into the business. Leadership should approve the scope in writing, assign an accountable owner for each Control, and confirm which departments and service providers fall within it. Several IG2 Safeguards depend on processes that must be written down and followed, such as service provider assessment, incident handling and vulnerability remediation, so they cannot be delivered by a technical team alone. Recurring costs also matter: log storage, monitoring, testing and periodic review continue after the first implementation. Ask leadership to agree on how findings from testing will be prioritized and funded before the work begins, because unresolved findings undermine the evidence an assessor will expect.
Where can I see how IG2 maps to other frameworks?
Use the CIS Controls Navigator for v8.1. As of October 2026, it offers CIS mappings to 30 frameworks and versions, including NIST CSF 2.0, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 and Rev. 3, ISO/IEC 27001:2022, SOC 2, PCI DSS v4.0, CMMC v2.0, DORA and NIS2. The Navigator lets you filter by Implementation Group, so you can see which mapped requirements the IG2 Safeguards touch. Treat these mappings as CIS's view, not as a finding that one framework satisfies another. Confirm the exact mapping with your auditor or assessor for the framework you are assessed against, and check the current Navigator version before you rely on a mapping in a contract or submission. The CIS Controls Navigator is the natural starting point.
Who owns IG2, who prepares evidence and who verifies it
The organization owns every IG2 Safeguard it adopts, and no implementation partner, tool or consultant can take that ownership over. The enterprise decides which Safeguards apply, assigns an accountable owner for each one and runs the processes day to day. An implementation partner can configure logging, segment networks, build the review cadence for vulnerability findings and write the procedures that describe how those things happen. What the partner cannot do is make the organization's risk decisions or sign off on its own exceptions. Before work starts, confirm in writing which party maintains each written process and which party holds each recurring task, especially for the six Control 16 and eleven Control 16 items that depend on developers following a process.
Preparing evidence is a separate job from verifying it. An implementation partner can assemble the artifacts that the CIS Controls Assessment Specification describes as inputs and measures, such as log configurations, scan exports, change records and access review sign-offs, and can organize them so an assessor can trace each Safeguard to its proof. The CIS Controls Assessment Specification says what to measure but not how, so the method and sampling used by whoever tests the Safeguards should be agreed early. Ask any provider to show a sample evidence pack for one IG2 Safeguard, including where the raw data lives and who can reproduce it.
Verification belongs to the organization or to a party it engages for an assessment, and a formal report or accreditation comes only from an independent body. CIS Controls Accreditation, run with CREST, accredits CIS SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services. It is not a certificate for an organization's own controls. Ask each provider whether it holds that accreditation for the specific service on offer, and check the status directly with CIS rather than relying on marketing language.
How DeployOpen scopes IG2 work and prepares the evidence
DeployOpen works on IG2 by first agreeing in writing which of the 74 added Safeguards apply to your environment, then building and documenting the platforms, logging, network monitoring and testing those Safeguards depend on. We run the self-hosted open-source platforms inside your own infrastructure and prepare the evidence, while your organization keeps ownership of its controls.
How we scope
- Engagements are fixed-scope, with the IG2 Safeguards in scope, deliverables and timelines agreed in writing before work starts.
- We map the 74 added Safeguards to your asset inventory, so the scope names which systems, networks and applications each one covers.
- The written scope states what your staff own, such as policies and approvals, and what DeployOpen prepares, such as platforms and evidence.
How we build
- We deploy and harden the self-hosted open-source logging, monitoring and vulnerability tooling inside your cloud accounts, data centers or air-gapped networks.
- We configure audit log collection, time synchronization and retention so that the Control 8 and Control 13 evidence can be produced from the platforms.
- We run application security and penetration testing against in-scope applications and APIs, and record findings and remediation status.
How we hand over
- We document each platform, configuration and procedure so your team can operate and explain the Safeguards it supports.
- We deliver evidence packages keyed to each in-scope Safeguard, showing what was configured, tested and reviewed, and when.
- We agree with your team what the independent auditor or assessor will need to see, since only an independent party issues reports or certificates.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Confirm with us during scoping which platform upgrades and testing cycles a retainer would cover, and get that in writing.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
