Safeguard 18.5: Perform Periodic Internal Penetration Tests

Safeguard 18.5 requires you to run periodic internal penetration tests that simulate an attacker operating from inside your environment, then track findings through remediation and retest. To operationalize it fast, define scope and rules of engagement, use qualified testers, prioritize realistic attack paths, and retain evidence that proves testing happened and weaknesses were fixed. ¹

Key takeaways:

• Internal penetration testing must be repeatable: defined scope, approved methodology, documented results, tracked remediation, and retesting.
• The control fails most often on evidence: unclear scope, missing approvals, no remediation proof, or no retest closure.
• Treat internal pen tests as validation of your security program, not a one-off “IT exercise.” Map it to recurring control operation and evidence capture. ¹

Safeguard 18.5: perform periodic internal penetration tests requirement sits in CIS Controls v8 as a practical validation control: you are expected to test what an attacker could do after gaining an initial foothold inside your network or cloud environment. That “internal” perspective changes the objective. The goal is not to find every bug; it’s to prove whether segmentation, identity controls, monitoring, and hardening actually prevent lateral movement and privilege escalation in real conditions. ¹

Compliance leaders usually inherit two problems here. First, the organization treats penetration testing as a procurement event instead of an operational control with defined inputs, repeatable execution, and durable evidence. Second, internal tests get confused with external tests, vulnerability scans, or automated tooling. Those are useful, but they do not replace an internal attacker simulation that chains weaknesses across identity, endpoints, and internal services.

This page translates Safeguard 18.5 into a requirement you can run: who owns what, what steps to execute, what artifacts to retain, and where audits get stuck. It also includes a practical phased plan and FAQs that match how teams actually work. ¹

Regulatory text

CIS Controls v8 safeguard 18.5 implementation expectation (Perform Periodic Internal Penetration Tests). ¹

Operator interpretation: You must plan and execute internal penetration tests on a recurring basis, document results, and drive remediation to closure. Internal means the tester starts with a position that represents an insider threat or an attacker who already compromised a user/workstation, then attempts to move laterally, escalate privileges, access sensitive data, or compromise critical systems. ¹

What “periodic” means in practice (without inventing a frequency): define a cadence in your control documentation that matches your risk and environment change rate, then follow it consistently. Auditors will accept different cadences, but they will not accept “ad hoc” as a control. ¹

Plain-English requirement

Run internal pen tests that reflect realistic internal attack paths, then prove you acted on the results. A passing implementation has:

• A written internal penetration testing standard (scope, methodology, approvals, tester qualifications, and safety controls).
• A documented test plan per cycle.
• A final report with reproducible findings and business impact.
• A remediation workflow with owners, due dates, and closure evidence.
• Retesting or validation that fixes worked. ¹

Who it applies to

Entities: Enterprises and technology organizations adopting CIS Controls v8. ¹

Operational context where this matters most:

• Hybrid identity (cloud IdP plus on-prem AD) where privilege boundaries blur.
• Flat internal networks or weak segmentation between user and server subnets.
• High-impact internal systems (finance, HR, code repositories, production management planes).
• Environments with meaningful insider risk (contractors, broad admin access, shared accounts).
• M&A or rapid growth where inherited network zones and admin models are inconsistent.

If you have critical workloads in cloud, treat “internal” as “from within your tenant/VPC/VNet with a compromised identity or workload,” not only a device plugged into an office switch.

What you actually need to do (step-by-step)

1) Name an owner and write the control statement

Assign control ownership (often Security/GRC with Security Engineering execution). Write a control statement that is testable:

• Purpose: validate resistance to internal attacker behavior.
• Frequency: your defined cadence.
• Scope baseline: core networks, identity, and critical applications.
• Outputs: report, remediation tickets, retest evidence.
• Exceptions: how you document exclusions and compensating controls. ¹

Daydream fit (natural): If you manage CIS alignment in Daydream, map Safeguard 18.5 to a recurring control operation with an evidence checklist so each test cycle produces consistent artifacts instead of “hero screenshots.”

2) Define scope using “crown jewels” and attack paths

Start with what an internal attacker would target:

• Identity systems (IdP, AD, PAM, MFA flows, service accounts).
• Admin planes (cloud consoles, Kubernetes, virtualization, network management).
• Sensitive data stores (customer data, financials, source code).
• Internal pivots (jump hosts, shared file servers, endpoint management tooling).

Write scope in two layers:

• In scope systems and networks (what can be touched).
• In scope objectives (what the tester is trying to achieve, such as lateral movement to a critical segment or privilege escalation to an administrative role).

3) Set rules of engagement (RoE) that prevent outages

Internal tests can break things. Your RoE should include:

• Allowed techniques vs prohibited techniques (for example, no denial-of-service).
• Time windows and change freeze coordination.
• Test accounts, logging requirements, and notification path if the tester finds active compromise.
• Data handling: how evidence is stored and redacted.
• Safety controls for production.

Keep RoE as an approved document with version control and sign-off by Security and IT owners.

4) Choose testers and methodology you can defend

Decide whether the test is performed by:

• Internal security team (requires independence and skills evidence), or
• A third party pen test firm (requires procurement diligence and contract language).

Either way, document:

• Tester qualifications (resume, certifications, or prior work samples).
• Methodology reference (what playbooks and reporting structure they follow).
• Independence and conflict management (avoid a team “grading its own homework” with no oversight).

5) Execute the internal penetration test with realistic starting assumptions

Common internal starting points to define explicitly:

• Compromised standard user workstation.
• Compromised VPN user.
• Compromised cloud workload identity.
• Access as a contractor with limited entitlements.

During execution, require the tester to record:

• Attack narrative (what they attempted and why).
• Evidence (commands, timestamps, affected systems, screenshots as needed).
• Control observations (where detection/response succeeded or failed).

6) Triage findings into remediation work that will actually close

Your remediation process needs more than “send the PDF to IT.” Minimum structure:

• Severity rating and rationale (you define the scale).
• A unique tracking ID per finding.
• Assigned owner (system owner, app owner, IAM owner).
• Target date and status.
• Risk acceptance workflow for items you can’t fix quickly, with approval and compensating controls.

7) Retest and close the loop

Plan retesting up front. For each high-risk finding, capture one of:

• Retest evidence confirming the exploit path is no longer possible, or
• Alternative validation evidence (configuration snapshots, access control proof, segmentation rules, detections) plus tester sign-off where feasible.

8) Feed results into program improvements

Internal pen tests should generate durable improvements:

• Update hardening baselines and build standards.
• Tune detections (SIEM/EDR alerts) based on attacker techniques observed.
• Improve segmentation and privileged access management.
• Adjust security training for admins if behavior created exposure.

This step matters in audits because it shows the test is a control improvement loop, not theater.

Required evidence and artifacts to retain

Maintain an evidence package per test cycle. Auditors typically want proof of design, execution, and follow-through:

Design evidence

• Internal penetration testing policy/standard (including cadence).
• Scope definition and asset/system inventory reference used for scope.
• Rules of engagement with approvals.
• Tester qualification evidence (internal role description/training records or third party SOW and firm credentials).

Execution evidence

• Test plan (objectives, dates, starting assumptions, in-scope targets).
• Final report (executive summary plus technical detail).
• Raw evidence repository location (with access controls) or redacted appendix.
• Meeting notes for readout and stakeholder acknowledgment.

Remediation evidence

• Tickets or work items mapped to each finding.
• Fix validation (retest results or alternative validation).
• Risk acceptance memos where applicable, with approvals.
• Closure report: findings status summary and lessons learned.

Daydream fit (natural): Use Daydream to tie Safeguard 18.5 directly to these artifacts so each cycle produces the same evidence set and you can answer audits from one record instead of hunting across email, ticketing, and shared drives. ¹

Common exam/audit questions and hangups

Use these to prep your control narrative:

1. “Show me your penetration testing cadence and the last completed internal test.”
   Hangup: you ran tests, but cannot show a documented schedule and completion proof.

2. “How did you select scope? What was excluded and why?”
   Hangup: scope looks arbitrary, or “internal” only covered a lab environment.

3. “Who performed the test and what qualifies them?”
   Hangup: internal team did it, but there’s no independence story or skills evidence.

4. “How do you ensure findings are remediated?”
   Hangup: findings live in a PDF with no ticket linkage, no owners, no closure.

5. “Did you retest high-risk findings?”
   Hangup: remediation is “reported complete,” but nobody verified exploitability is gone.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating vulnerability scans as “pen testing”	Scans enumerate; pen tests chain paths and validate impact	Keep scans, but run a true internal attacker simulation and document the narrative
No written rules of engagement	Creates outage risk and “shadow testing” concerns	Require RoE sign-off before testing begins
Testing only network ports	Misses identity and privilege paths	Make identity escalation and lateral movement explicit objectives
Findings have no owners	Remediation stalls and repeats every cycle	Assign owners per system and track in tickets
No retest	You can’t prove risk reduction	Schedule retest windows and require closure evidence
Over-scoping	The test becomes unfinishable; results are shallow	Start with crown jewels and top attack paths, expand iteratively

Risk implications (why operators care)

Internal attacks are a common real-world pattern: phishing, credential theft, or compromised endpoints often precede lateral movement and privilege escalation. If you cannot demonstrate internal testing and remediation, you lack evidence that segmentation, IAM, and monitoring controls work under adversarial pressure. That gap increases breach impact when an external control fails.

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign owner and define control language for Safeguard 18.5. ¹
• Draft policy/standard: scope approach, cadence, RoE template, evidence checklist.
• Identify crown jewels and shortlist internal attack paths (identity, admin planes, key apps).
• Decide tester model (internal vs third party) and start procurement if needed.
• Build the evidence folder structure and ticket mapping approach.

Next 60 days (run the first cycle)

• Finalize scope and RoE approvals with IT and business owners.
• Execute the internal penetration test.
• Deliver report and hold a formal readout meeting.
• Convert findings into tracked remediation work with owners and target dates.
• Define retest criteria per critical/high findings.

Next 90 days (close findings and operationalize recurring execution)

• Retest or validate remediation for the highest-risk findings.
• Produce a closure memo or dashboard showing status and risk acceptances.
• Update security standards (hardening, IAM, segmentation) based on lessons learned.
• Lock the next test window on the calendar and refine scope based on changes in environment.
• In Daydream, attach artifacts to the Safeguard 18.5 control record and set reminders for recurring evidence capture. ¹

Frequently Asked Questions

Does an internal vulnerability scan satisfy safeguard 18.5: perform periodic internal penetration tests requirement?

No. Scans are input to a pen test, but Safeguard 18.5 expects an internal attacker simulation with exploit chaining, impact validation, and documented remediation follow-through. ¹

Can our internal security team perform the internal penetration test?

Yes, if you can document competence and address independence concerns with oversight, peer review, or separate reporting lines. Keep strong evidence: methodology, test plan, and reproducible results. ¹

What should “internal” mean in a cloud-first company with few office networks?

Define internal as operating from within your cloud environment or tenant with a compromised identity or workload. Scope should include cloud IAM paths, management planes, and internal service-to-service trust, not only office LAN segments.

How do we handle systems we cannot test due to uptime or safety constraints?

Document exclusions with rationale, add compensating controls (segmentation, monitoring, configuration validation), and schedule alternative testing windows or methods. Auditors look for governance and risk acceptance, not perfection.

What evidence is most persuasive to auditors?

A signed RoE and test plan, a final report, tickets mapped to each finding, and retest proof for high-risk items. Weak evidence is a PDF report with no remediation traceability.

How do we prevent pen tests from becoming a repeat list of the same findings?

Treat recurring findings as program defects: update build standards, enforce configuration baselines, and require closure validation. Use the next cycle to test whether the systemic fix removed the underlying attack path.

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8