What CIS Controls IG3 adds on top of IG2
IG3 adds 23 Safeguards to the 130 in IG1 and IG2, bringing the total to 153, and they cover intrusion prevention and advanced network defense, service provider monitoring, application threat modeling and secure code checks, and internal penetration tests. When a regulator, customer or board asks whether the enterprise meets the top Implementation Group, the answer starts with two questions: does the enterprise employ security specialists in areas such as risk management, penetration testing or application security, and does it hold data under regulatory oversight while facing targeted attacks from sophisticated adversaries? CIS describes IG3 for that profile in its Implementation Group 3 definition. A yes to both points toward IG3. A no to either means the enterprise should confirm its target group before committing budget.
The 23 additions concentrate in a few Controls. Control 13, which covers network monitoring and defense, gains five Safeguards (13.7 to 13.11). Control 16, which covers application software security, gains three (16.12 to 16.14). Control 15, which covers service provider management, gains three (15.5 to 15.7). Control 18, which covers penetration testing, gains two (18.4 and 18.5). Control 3 and Control 17 each add a smaller number. Those items account for 16 of the 23, so confirm the remaining seven in the assessment specification instead of assuming their location. Assign an owner to each IG3 Safeguard now, because the Control 13 items depend on monitoring tooling and the Control 16 items depend on developer workflows that the security team may not run.
Responsibility splits three ways. The enterprise owns each Safeguard and decides how it applies to its environment. An implementation partner such as DeployOpen can plan, deploy and harden self-hosted open-source platforms that support these Safeguards, and prepare the configurations, logs and test reports that show them working. Only an independent assessor or auditor judges whether the Safeguards are implemented and issues any report. Before signing, ask for a written scope that names which of the 23 Safeguards are included, which the enterprise will keep in-house, and what evidence each one will produce. Confirm with the assessor which measures they will test, so the evidence matches what will be examined.
Which attack surfaces the IG3 Safeguards cover
The 23 IG3 Safeguards extend the program into five areas: network defense against targeted intrusions, oversight of service providers, secure software review, internal penetration testing, and data and incident readiness. Each card names what the Safeguards ask for, what an assessor would expect to see, and the part of the control the organization must own itself.
Advanced network defense
Control 13 adds five Safeguards at IG3, 13.7 to 13.11, for enterprises facing sophisticated, targeted attacks. They ask for host-based intrusion prevention and network-level intrusion prevention that can act on traffic, not only alert on it, along with the tuning that keeps those tools accurate. An assessor would look for configuration exports, tuning records and sample blocked events. The organization owns the detection and prevention decisions, and an implementation partner can prepare the sensor deployment and evidence.
Service provider monitoring
Control 15 adds 15.5 to 15.7 at IG3. These Safeguards ask the organization to assess the security posture of critical service providers on a recurring basis, not only at onboarding, and to act on what the reviews find. An assessor would expect a current inventory of critical providers, review records with dates and findings, and evidence that issues were tracked to closure. The contractual and risk decisions stay with the organization, even when a partner helps build the review workflow.
Threat modeling and code checks
Control 16 adds 16.12 to 16.14 at IG3, covering code-level security checks and threat modeling for software the enterprise builds or relies on. Expect the organization to review application designs for threats before release and to run static or dynamic analysis as part of the development pipeline. An assessor would ask for threat model documents, pipeline configuration and sample findings with their resolution. The development teams own the secure design decisions, while security staff or a testing partner can supply the tooling and review evidence.
Internal penetration testing
Control 18 adds 18.4 and 18.5 at IG3. They extend testing beyond the perimeter so that the internal network, its trust relationships and its users are tested for exploitable weaknesses. An assessor would look for a written test scope, rules of engagement, reports with exploited paths and a remediation log showing how each finding was closed and retested. The organization decides scope and accepts risk, and an independent tester performs the work, which is why testers should be chosen with care.
Data protection at IG3
Control 3 adds two Safeguards at IG3 on top of the six IG1 and six IG2 Safeguards. These extend data protection to the sensitive data held under regulatory oversight that IG3 enterprises typically keep. An assessor would expect the data inventory and classification records to show where regulated data sits, plus evidence that protections such as encryption and access restrictions were applied to it. The data owners remain accountable for classification decisions, and partners can help map data stores and collect proof.
Incident response at IG3
Control 17 adds one Safeguard at IG3, 17.9. It covers the incident response capability at the level expected of enterprises with specialist staff and regulated data. An assessor would look for response plans and records of exercises, and for evidence that lessons from incidents changed the process. Leadership must own the response decisions and reporting obligations, and an external partner can run exercises or review the plan, but cannot make those decisions on the organization's behalf.
Where the 23 CIS Controls IG3 Safeguards land, Control by Control
Control 13 covers monitoring and defending the enterprise network and user base. IG2 adds six Safeguards here (13.1 to 13.6) for centralized alerting, intrusion detection, segment filtering, remote access control and flow logs. IG3 adds five more, 13.7 to 13.11, which move the program from detecting attacks toward stopping them and tuning alerts so they stay useful. The IG3 Safeguards in this Control are:
- 13.7 and 13.8: host-based and network-based intrusion prevention, which block suspicious activity in addition to alerting on it.
- 13.9: port-level access control lists that restrict traffic between network segments.
- 13.10: application-layer filtering for traffic crossing the network boundary.
- 13.11: tuning of security event alerting thresholds so that alerts remain actionable.
An IG3 team's first step is to take the IG2 alert output for one segment, measure how many alerts lead to action, and pilot prevention mode on a non-production segment before enabling blocking across the estate. Confirm with your intrusion prevention vendor which of 13.7 to 13.11 its product supports, and check exact Safeguard titles in the v8.1 list.
Control 15 covers evaluating service providers that hold sensitive data or run critical IT platforms or processes. IG2 adds three Safeguards (15.2 to 15.4) that cover the provider inventory, classification, contract security requirements and initial assessment. IG3 adds three more, 15.5 to 15.7, which keep provider risk current across the life of each relationship. The IG3 Safeguards in this Control are:
- 15.5: assessment of service providers against their classification and contract requirements.
- 15.6: monitoring of provider security posture over time, not only at onboarding.
- 15.7: secure decommissioning of provider access and data when a relationship ends.
An IG3 team's first step is to rank its IG2 provider inventory by data sensitivity and operational criticality, then start assessments with the providers that hold the most regulated data. Ask each provider for its current independent assurance reports and any penetration test summaries. Only the provider's own independent auditor can issue those reports, so the assessment should request them rather than treat a questionnaire alone as evidence. Confirm the exact Safeguard titles in the CIS Control 15 page and the v8.1 list.
Control 16 covers the security life cycle of software the enterprise develops, hosts or acquires. IG2 adds eleven Safeguards (16.1 to 16.11) for a secure development process, vulnerability handling, third-party components, environment separation and developer training. IG3 adds three more, 16.12 to 16.14, which bring code-level checks, application testing and design-stage risk analysis into the process. The IG3 Safeguards in this Control are:
- 16.12: code-level security checks, such as static and dynamic analysis, built into the build pipeline.
- 16.13: application penetration testing against production-like environments.
- 16.14: threat modeling for applications before major design changes are built.
An IG3 team's first step is to pick one business-critical application, add a code-level check to its existing pipeline, and record the findings alongside the developer training and vulnerability records that IG2 already requires. Confirm the exact Safeguard titles in the v8.1 list, and confirm with your tooling vendors which checks they can run as part of a pipeline. Keep the threat model and the test results in the same repository as the code so an assessor can trace a finding to its fix.
Control 18 covers testing how effective and resilient enterprise assets are by finding and exploiting weaknesses in people, processes and technology. IG2 adds three Safeguards (18.1 to 18.3) that establish the testing program, external tests and remediation of findings. IG3 adds two more, 18.4 and 18.5, which extend the program inward and make remediation verifiable. The IG3 Safeguards in this Control are:
- 18.4: remediation of penetration test findings, with each finding tracked to closure and validated.
- 18.5: periodic internal penetration tests that assume an attacker has already reached the internal network.
An IG3 team's first step is to define an internal test scope that starts from a compromised user account and follows the paths that an attacker could use to reach sensitive systems. Set up a finding tracker that records owner, due date and validation evidence for each item. DeployOpen performs internal and application security testing as a service, but the organization owns the testing program, its scope decisions and the remediation records. Ask any tester to confirm in writing which systems are in scope and how findings will be validated before the test begins.
Control 3 covers data protection, and Control 17 covers incident response management. Control 3 adds two Safeguards only at IG3, which the v8.1 list should confirm as 3.13 and 3.14. Control 17 adds one Safeguard only at IG3, 17.9, after IG2 adds five (17.4 to 17.8) for the response process, roles, communication, exercises and post-incident reviews. The IG3 Safeguards in these Controls are:
- 3.13: data loss prevention, which monitors and controls the movement of sensitive data out of the enterprise.
- 3.14: logging of access to sensitive data, so that reads and transfers can be reviewed after the fact.
- 17.9: security incident thresholds, which define when an event becomes an incident that triggers escalation.
An IG3 team's first step is to link these three items. Start with a data inventory from IG2, decide which data classes trigger data loss prevention and access logging, and write incident thresholds that name those events. Confirm the Safeguard IDs for Control 3 against the CIS Controls Assessment Specification for v8.1 before scoping, because the supplied facts state only the counts for this Control. Keep the thresholds in the incident response plan so an assessor can match each threshold to its trigger.
How to add the IG3 Safeguards on top of IG2
This sequence takes an enterprise that already runs IG2 and extends it to the 23 IG3 Safeguards, producing a confirmed scope, named owners, measured evidence, tested controls and an evidence pack that an independent assessor can review.
Confirm the IG3 profile against CIS
Start by checking whether the organization actually fits the IG3 profile described on CIS's Implementation Group 3 page. That profile covers enterprises with dedicated security specialists, regulated or sensitive data, and exposure to targeted attacks from sophisticated adversaries. Leadership, risk and security staff should document the reasons for or against IG3 in a short profile memo. The output is a signed profile decision that states which Safeguards are in force and why, so the rest of the work has a clear starting point.
Scope systems, data sets and providers
Next, define which systems, data sets and service providers the IG3 Safeguards apply to. Include the environments where regulated or sensitive data lives, the network segments that need intrusion prevention, and the providers that hold that data or run critical services. Record any systems excluded from scope and the reason. The output is a written scope statement with an asset list that the owners in the next step can sign against. Ask your assessor early whether they expect a particular boundary.
Assign an owner to each Control
Assign a named accountable owner to each CIS Control that carries IG3 Safeguards, including Control 13 (network monitoring and defense), Control 15 (service provider management), Control 16 (application software security), Control 17 (incident response management), Control 18 (penetration testing) and the IG3 items under Control 3 and Control 13. Each owner needs authority to approve changes and accept risk. The output is an owner register listing each Safeguard, its owner, its backup and the review cycle the owner has committed to.
Build evidence against the assessment specification
For each IG3 Safeguard, use the CIS Controls Assessment Specification as the measurement reference. The specification states what inputs, operations, measures and metrics verify a Safeguard, so it tells you what records to produce. Map each Safeguard to its artifacts, such as intrusion prevention configuration exports, provider assessment questionnaires, threat models, code review records and penetration test reports. Remember that CIS says the specification covers what to measure, not how, so the method you choose must be documented. The output is an evidence matrix that links each Safeguard to its artifacts and collection method.
Test the controls and close findings
Test each IG3 control against its evidence matrix entry, including the internal penetration tests covered by Control 18. Testing should check that intrusion prevention blocks what it is configured to block, that provider assessments were completed for in-scope providers, and that threat models and code-level checks were carried out on the applications named in scope. Log every failure as a finding with an owner and a remediation plan, then retest before closing it. The output is a test report with a findings log showing each closed item and its retest result.
Prepare the evidence pack for an independent assessor
Assemble the evidence pack: the signed profile memo, the scope statement, the owner register, the evidence matrix, the test report and the findings log, with the underlying artifacts indexed. Confirm that dates, versions and approvals are consistent across documents. Then share the pack with the independent assessor you have chosen. Be clear that DeployOpen prepares systems, controls and evidence but does not issue reports or certifications, and that only the independent assessor can give an opinion on the outcome. The output is an indexed evidence pack ready for the assessor's review and a list of questions to confirm with them before fieldwork begins.
What usually delays IG3 work and how to avoid it
IG3 work rarely stalls on technology alone. The delays below tend to come from missing process documents, unmapped vendors, development practices kept outside the life cycle, and unclear ownership. Each card gives one step your team can check internally before committing budget or scheduling assessments.
Buying tools before writing processes
Many IG3 Safeguards ask for a documented process that is then performed and measured, and no product writes that process for you. Before purchasing intrusion prevention or monitoring tooling, confirm that each Safeguard in Controls 13, 15, 16, 17 and 18 has a written procedure, a named operator and a record that the procedure ran. Ask any vendor which of these artifacts its product generates and which you must still author.
Skipping the service provider inventory
Control 15 asks you to classify providers that hold sensitive data or run critical platforms before you can assess or monitor them. Teams that start with contract reviews often find they cannot say which vendors are in scope. Build a single provider inventory with data types, criticality and contract owner first, then decide which providers receive the IG3 assessment and monitoring steps.
Keeping threat modeling outside development
Threat modeling and code-level checks under Control 16 lose value when they run as a one-time review after release. Place threat modeling at design review and code checks in the merge pipeline, and record the findings in the same tracker developers already use. Confirm that a sample of recent changes shows a threat model reference and a completed code check, since assessors look for that trail rather than a policy statement.
Scheduling penetration tests without remediation steps
Control 18 covers the testing program, but a report with no owner, deadline or retest plan leaves the findings open. Before booking an internal or external test, write the remediation workflow: who triages each finding, how severity is assigned, how fixes are verified and who signs off the retest. Ask the tester to produce findings in a format your tracker can ingest so closure can be shown.
Starting without Safeguard-level owners
IG3 spans 23 added Safeguards across several Controls, and a single security lead rarely performs all of them. Without a named owner for each Safeguard, evidence gets collected by whoever is available and gaps surface during assessment. Create a table listing each Safeguard, its owner, its evidence location and its review date, and confirm each owner accepts the role in writing before work begins.
Who owns, who prepares and who assesses each IG3 Safeguard
The organization owns every IG3 Safeguard, regardless of who helps build the tooling. Ownership means the Safeguard is part of the enterprise's own security program, is approved by its leadership, and is run by its own people. Outside help can change how a control is built, but it cannot take over the decision to accept a risk or the duty to operate the control every day.
- Controls and policies: Set the written processes that IG3 Safeguards depend on, such as threat modeling, service provider assessment and penetration test remediation, and keep them current.
- Risk decisions: Decide which threats matter, which residual risks are accepted, and who signs off on exceptions.
- Staff: Employ or contract the security specialists in risk management, penetration testing and application security that IG3 describes, and keep their skills current.
- Daily operation: Run the intrusion prevention, logging, alert triage and incident handling that generate evidence over time.
- Accountability: Name an accountable owner for each Safeguard so an assessor can see who answers for it.
Check that every IG3 Safeguard has a named internal owner and a written process before you engage any partner.
An implementation partner such as DeployOpen works inside the organization's own infrastructure to prepare the systems, configurations and evidence that IG3 Safeguards need. The work follows a written scope agreed before it starts. The partner does not own the controls, does not make the organization's risk decisions, and does not sign any assessment outcome.
- Planning and design: Map the agreed Safeguards to specific systems, tools and data flows, and document the design.
- Configuration: Deploy and harden self-hosted open-source platforms for logging, intrusion detection, vulnerability tracking and similar functions.
- Evidence preparation: Set up the records, exports and dashboards that show a control operating, so the organization can give them to an assessor.
- Security testing: Run internal penetration tests and application security tests within the written rules of engagement.
- Documentation and handover: Produce runbooks and configuration records that the organization's staff can operate after the engagement ends.
Confirm in the written scope exactly which Safeguards are in scope, what deliverables you receive, and what the partner will not do, including issuing any report or certificate.
An independent assessor tests whether the controls are in place and operating. Depending on the reason for the assessment, this may be an auditor, a certification body, a CIS Controls accredited organization, or another qualified assessor. Only the assessor issues a report, attestation or certificate. The assessor must be independent of the organization and of any partner that helped build the controls.
- Testing: Review policies, sample records, inspect configurations and interview staff against the test procedures that apply to each Safeguard.
- Reliance on evidence: Decide whether the evidence is complete, consistent and traceable to the Safeguard.
- Reporting: Issue any report, attestation or certificate under the assessor's own authority and terms.
- Scope limits: Test only the scope the organization defines, so the boundaries matter as much as the controls.
- Independence: Avoid roles that create a conflict, such as designing the controls and then testing them.
Confirm with the assessor which test procedures they will use, and whether they accept CIS Controls evidence for the framework you must report against.
What completing IG3 does not prove
Finishing the 23 IG3 Safeguards does not make an organization compliant with any regulation, and CIS says so directly: the CIS Controls do not replace any regulatory, compliance or authorization scheme. A bank, hospital or operator under DORA, NIS2, HIPAA or a sector rule still has to show how its obligations are met, and an assessor will test those obligations on their own terms. The CIS Controls can supply much of the technical evidence for that work, but they do not decide which obligations apply or whether they are satisfied. Treat IG3 completion as one input to a compliance program, not a finding that the program passes.
The Community Defense Model analysis cited in CIS's September 2026 press release found that implementing all CIS Controls Safeguards defends against 99% to 100% of techniques across the five attack categories studied. That describes technique coverage within that study's scope and dataset. It is not a guarantee against breach, and it says nothing about how well any individual Safeguard is operated in your environment, how quickly you detect an intrusion, or whether a new attack method falls outside the techniques the study examined. Ask your team to document which attack categories and environments your own testing covers so the result is not read as a general claim.
For mapping to other frameworks, start with the CIS Controls Navigator for v8.1, which lists CIS mappings to NIST CSF 2.0, ISO/IEC 27001:2022 and other frameworks. A mapping shows where a Safeguard is related to a requirement in another framework; it does not show that the requirement is met. Before you rely on a mapping in a contract, audit or regulatory submission, confirm it with the framework owner or your assessor, and confirm the framework version your auditor will use. Where the mapping is thin, the gap is yours to close with separate controls and evidence.
Questions buyers ask about CIS Controls IG3
Must an enterprise implement IG3 to be considered secure?
No. CIS defines IG1 as essential cyber hygiene and a minimum standard for every enterprise, so IG1 is the baseline every organization should meet first. IG2 adds Safeguards for enterprises with more operational complexity that often hold sensitive information, and IG3 adds the final 23 Safeguards for enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks. Which group applies depends on your staffing, the sensitivity of your data and the threats you face. Confirm your Implementation Group against the profiles on the CIS Implementation Groups page and decide with your risk owners which Safeguards your environment actually needs, then document that decision in writing.
Does implementing IG3 lead to a CIS certification?
No. CIS Controls implementation is not a certification, and the CIS Controls do not replace any regulatory, compliance or authorization scheme. Evidence that a Safeguard is in place is produced by your organization, and any independent statement about it comes from a separate assessor or auditor engaged for that purpose. CIS Controls Accreditation, run with CREST, applies to CIS SecureSuite member organizations that provide implementation, auditing or assessment services, so check any firm's accreditation status directly with CIS rather than assuming it. An implementation partner can prepare systems and evidence, but it does not issue reports or certificates.
What staff does IG3 require the organization to have?
CIS describes IG3 enterprises as employing security specialists, for example in risk management, penetration testing or application security. In practice that means the IG3 Safeguards in Control 13 (network monitoring and defense), Control 15 (service provider management), Control 16 (application software security) and Control 18 (penetration testing) need named people who can design detections, review third-party risk, perform threat modeling and code-level checks, and interpret penetration test findings. Small teams often cover these roles with a few individuals plus external specialists. Ask any partner who will perform each Safeguard, what skills they bring and how knowledge transfers to your staff.
Can our own team implement the IG3 Safeguards without outside help?
Yes, many organizations do, provided each Safeguard has a named owner, a written process and retained evidence. The CIS Controls Assessment Specification defines the inputs, operations, measures and metrics used to verify each Safeguard, but it states what to measure rather than how, so your team still has to design the process. Start by mapping each IG3 Safeguard to an owner, a tool and an evidence location, then test whether the evidence is complete and repeatable. Outside help is most often used for specialist work such as penetration testing, threat modeling or tuning detections, while your team retains ownership of the controls themselves.
What decisions does leadership need to make before IG3 work starts?
Leadership needs to make three kinds of decision. First, scope: which systems, data sets, business units and service providers fall within the Safeguards. Second, risk acceptance: which Safeguards are deferred, compensated or declared not applicable, and who signs off on each exception. Third, funding and staffing: who owns each Safeguard, how much specialist time is available and which recurring tools and services are approved. Written decisions on these points shorten quoting and prevent disputes at assessment time. Most engagements are fixed-scope, so the scope decision should be agreed in writing before any work starts.
How do we confirm the IG3 Safeguard IDs and their Controls before requesting a quote?
Confirm each Safeguard ID against the official CIS Controls v8.1 list before you ask for a quote, because a scope written against the wrong ID leads to rework. The IG3 additions sit in Control 13 (13.7 to 13.11), Control 15 (15.5 to 15.7), Control 16 (16.12 to 16.14), Control 17 (17.9), Control 18 (18.4 to 18.5) and Control 3 (3.13 and 3.14). Check each entry against the CIS Controls v8.1 page, read the matching Assessment Specification entry for its measures, and ask your provider to repeat the Safeguard IDs and their Controls back in the written scope. Any mismatch should be resolved before pricing.
How DeployOpen scopes and prepares IG3 Safeguards
DeployOpen works on the IG3 Safeguards as part of a written, fixed scope that names which Safeguards, systems and evidence are in play. We prepare the platforms, controls and documentation that support each Safeguard inside your own infrastructure, while your organization owns its controls and an independent assessor decides what passes.
How we scope
- Agree in writing which of the 23 IG3 Safeguards apply to your environment and which already exist
- Map each in-scope Safeguard to its asset class, owner and the systems that hold its evidence
- Confirm which Safeguards your existing security specialists or service providers will keep running
- Set out deliverables, exclusions and timelines before any work starts, since most engagements are fixed-scope
How we build
- Deploy and configure self-hosted open-source tooling for intrusion prevention, logging and threat modeling in your accounts or data centers
- Document the processes the assessment specification expects, such as service provider and application security reviews
- Set up internal penetration testing and code-level checks that produce repeatable, reviewable results
- Test each control against the measures in the assessment specification and record what the evidence shows
How we hand over
- Deliver configuration records, runbooks and an evidence index that maps each Safeguard to its artifacts
- Document known gaps and open items so your team and assessor can see the current state without interpretation
- Train your staff to operate, review and update the tooling and the evidence it generates
- Make clear that DeployOpen prepares systems and evidence, while only an independent auditor or certification body issues reports or certificates
How we support
- Offer ongoing support, upgrades and continuous testing through a retainer agreed in writing
- Revisit in-scope Safeguards when the CIS Controls, your environment or your regulatory obligations change
- Support your team during assessor queries by providing the underlying evidence and configuration history
- Agree the support scope, response expectations and review cadence in the written retainer before work begins
