Safeguard 18.1 Penetration testing program requirements

What Safeguard 18.1 requires before any test is run

Safeguard 18.1 asks for a documented penetration testing program, sized to the enterprise, that sets scope, frequency, limitations, points of contact, remediation routing and retrospective requirements before any test begins. If you are an IG2 or IG3 enterprise preparing for a CIS Controls assessment, the question an assessor will ask first is whether that program exists as written documentation. The safeguard applies to IG2 and IG3 enterprises, not IG1, and the CIS Controls Assessment Specification lists no prerequisite safeguards for measuring it. The size and maturity of your enterprise, its industry and its complexity set how detailed the program needs to be, so a small IG2 organization and a large IG3 organization will write very different documents that still cover the same components.

The risk this safeguard addresses is testing that happens ad hoc: a tester is engaged on short notice, nobody agrees what is in bounds, production systems are tested during business hours without a rollback plan, and findings land in an inbox with no owner. The Documentation asset class and the Govern security function explain why the safeguard sits where it does. The asset is the written program itself, and the Govern function is the governance layer that decides who approves scope, who accepts risk and how often the program is reviewed. Because the program is measured for completeness, the assessor checks the document against the minimum components rather than the quality of any single test.

The hard part is rarely writing the document. It is getting security, IT operations and business owners to agree on scope and limits. Business owners may refuse to let a revenue system be tested, IT may require testing windows that exclude peak periods, and security may want broader attack types than operations can tolerate. Before drafting, confirm who signs off on scope, which systems are excluded and why, which attack types are excluded, and who receives findings at each severity. Check your draft against the Completeness measure in the assessment specification, and record the sign-off so the program has an owner when the first test is scheduled.

Which scope decisions a penetration testing program must cover

Safeguard 18.1 expects the program documentation to fix what is tested, when, and under what limits before any tester starts. The cards below cover the decisions that change the work most: asset classes, cloud and SaaS terms, third-party permissions, and test windows and exclusions.

Network, application, API and premise scope

The safeguard names network, web application, API, hosted service and physical premise controls as program characteristics. Each category needs a stated decision: in scope, out of scope, or tested only under a named condition. Record the owner of each target so the scope can be checked against the asset inventory. Ask whether physical controls such as badge access and facility entry are tested at all, and who approves that work, because the answer changes the team, the permissions and the paperwork.

Asset classes in scope

The program should state which asset classes it covers: devices, software, data, users, network and documentation. Testing user accounts and documentation, such as runbooks or wiki pages that expose credentials or architecture, is a different exercise from testing devices. Document which classes are excluded and why. A scope that names only servers often misses the paths attackers use most, including identity systems and internal knowledge bases.

Cloud and SaaS testing terms

Before scoping cloud or SaaS targets, read the testing terms of each provider. Some providers allow customers to test their own resources under defined rules and forbid testing of shared infrastructure. Others require prior notice or approval for certain attack types. Confirm these terms in writing with the provider or in its published policy, and record which resources fall under them. Treat any target without clear terms as out of scope until the terms are confirmed.

Third parties needing written permission

Hosted platforms, managed service providers, payment processors and outsourced developers may own or operate in-scope systems. Testing those systems without written permission from the owner can breach contracts and create legal exposure. Build a list of third parties that touch in-scope assets, obtain signed authorization from each owner, and set the dates the authorization covers. Keep the authorizations with the program documentation so a tester can show permission for every target.

Acceptable hours and excluded attack types

The limitations section sets when tests may run and which techniques are off limits. Common limits include testing windows that avoid month-end processing, a rule against denial-of-service attacks on production, and bans on social engineering of named staff without approval. Each limit should name a decision owner and a reason. Vague wording such as no disruptive testing leaves testers guessing, so specify the actual techniques and hours, and state what happens if a test causes an outage.

How an assessor tests the penetration testing program

This table shows how an assessor applies the Completeness metric to Safeguard 18.1, from reviewing the written program to confirming it is in use. Read each row as a test step paired with the evidence it produces and the gaps that most often lower the score. The main takeaway is that a program that exists on paper but lacks required components, approval or current status will not pass.

Assessment step	What the assessor checks	Evidence or common finding
Completeness metric	Share of minimum program components present in the documentation	Score depends on how many required components the written program contains
Existence check	Whether any penetration testing program documentation exists	No documentation results in a failing score for Safeguard 18.1
Review the written program	Document covers scope, frequency, limitations, contacts and remediation routing	Program document with each component clearly stated
Program characteristics	Scope includes relevant assets such as network, web application, API, hosted services and physical premises	Scope section naming in-scope asset types, not a general statement
Approval record	Program was approved by appropriate leadership and is current	Signed or recorded approval with a review date
Scope and rules of engagement	Acceptable hours, excluded attack types and limits are defined	Rules of engagement document or limitations section
Contact list	Named points of contact for testers and internal owners	Current contact list with roles and escalation paths
Remediation routing	Findings are routed to owners under the vulnerability remediation process	Routing rules linked to ticketing or remediation records
Confirm the program is in use	Tests have actually been planned or run against the documented program	Test schedules, statements of work or prior test reports
Common finding: missing frequency	No stated testing cadence	Program lists a frequency and the schedule matches it

How to build the program document in five steps

This sequence turns Safeguard 18.1 into a signed, version-controlled penetration testing program document that states scope, frequency, limits, contacts, remediation routing and retrospective rules, so that each later test runs under the same written rules.

Confirm size, complexity, industry and maturity
Start by recording the facts that set how large and how formal the program must be: the number and type of enterprise assets, the systems that hold sensitive data, the regulations that apply, and how mature current security testing already is. The internal security lead owns this step, with input from IT and the business owners of critical services. The output is a short written rationale that explains why the program is sized the way it is. The step is done when a reviewer can trace each later decision in the document back to this rationale.
Draft scope and frequency with asset owners
Work with the owners of each asset group to list what may be tested: network ranges, web applications, APIs, hosted services and, where relevant, physical premise controls. Agree how often each category is tested and which tests are internal or external. Record the agreed scope as an inventory-linked list so that every in-scope item has a named owner. The output is a draft scope and frequency table, and the step is complete when every owner has confirmed their items in writing.
Define limitations and acceptable hours with operations
Meet with operations and change management to set the rules that keep testing safe for live services. Document acceptable testing windows, attack types that are excluded, systems that must not be touched, and stop conditions that halt a test. Operations should review these limits against the change calendar and business peaks. The output is a limitations section with testing windows and exclusions, approved by the operations lead. The step is done when no in-scope system lacks a stated limit or a stated reason for having none.
Name contacts and set remediation routing
Name the people who run, receive and act on each test: the tester contact, the internal sponsor, the operations contact who can stop a test, and the owners who fix findings. Connect the program to the existing vulnerability management process so that findings flow into the same ticket queue, severity scale and remediation timelines that the enterprise already uses. The output is a contact list and a routing diagram or table. The step is done when a sample finding can be traced from discovery to a named remediation owner without asking anyone who should receive it.
Set retrospectives, approve and store under version control
Define when a retrospective is held after each test, who attends, and what it must record, including lessons for scope, limits and routing. Then have the document approved by the accountable executive and record the approval date and version. Store the signed document in a wiki or document system that keeps a full change history, so every revision shows what changed, when and by whom. The output is an approved, versioned program document. The step is done when the approved version is the one readers can find, and prior versions can be compared and restored. An independent reviewer can strengthen this step, since a second reader often spots gaps that the authors have stopped seeing.

Why the program must be used, not only written

An assessor testing Safeguard 18.1 will not stop at the program document. The document shows intent, but the operating record shows whether the program runs: signed-off test reports, the scheduling decisions behind each engagement, remediation tickets linked to findings, and retrospective notes that record what changed after each test. Before an assessment, check that every scope, frequency and limitation written in the program has at least one dated record behind it. If the document promises annual external testing and quarterly reviews of exclusions, the file should show when those happened, who approved them and what was decided. A program with a complete policy and no trail of use is the most common gap a reviewer finds first.

The program is the governing layer for the four safeguards that follow it. Safeguard 18.2 covers external tests, Safeguard 18.5 covers internal tests, Safeguard 18.3 covers remediation of their findings, and Safeguard 18.4 covers validating security measures after testing, a step that applies to IG3 enterprises. Safeguard 18.1 sets who is contacted, how findings are routed into the documented remediation process and what each retrospective must answer. Those rules are where the sibling safeguards get their scope and their owners, so a gap in 18.1 usually shows up as a confused handoff in 18.3 or 18.4. Confirm that the contacts named in the program match the people who actually receive and act on the reports.

The same operating record also serves other frameworks. The CIS Controls Navigator maps Safeguard 18.1 to ISO/IEC 27001:2022 Annex A control 8.8 and to PCI DSS v4.0 requirements 11.1, 11.1.1, 11.4, 11.4.1, 11.4.2 and 11.4.3, and to NIST SP 800-53 Rev. 5 control CA-8(1). Those mappings are useful for planning, but they do not mean one report satisfies every framework. Ask each assessor which evidence they accept for penetration testing and whether they need the test methodology, the scope letter or the retest results. Organizations that already hold ISO 27001 or PCI DSS obligations should build one shared test calendar and one remediation record rather than parallel files. The independent auditor or certification body decides whether the evidence is sufficient.

Evidence that shows the program exists and is followed

Safeguard 18.1 is judged on documentation first, so an assessor will look for a program document that is approved, versioned and reviewed on a schedule. The artifacts below connect that document to each test, the people who act on findings and the record of how the program has changed over time.

Approved program document with version history

This is the penetration testing program itself, covering scope, frequency, limitations, points of contact, remediation routing and retrospectives. The Assessment Specification scores it on how many minimum components it includes, and it fails outright if no documentation exists. Keep it in a wiki with version control so every change shows what changed, when and by whom, and so earlier approved versions can be compared or restored. The owner is typically the CISO or the security function lead, who signs off each version.

Scope and rules of engagement per test

For each test, record the in-scope systems (network, web applications, APIs, hosted services, and physical premises where relevant), the acceptable testing hours, excluded attack types, and the testing method. Store the signed rules of engagement with the test record so an assessor can match the documented limits to what the tester actually did. The security function owns each document, and legal or the business owner of the system approves it before testing starts. Confirm that out-of-scope systems are excluded in writing.

Contact and escalation list

List the named people or roles who run tests, receive findings, approve emergency stops and notify management or regulators. Each entry needs a primary and backup contact, a method of reaching them outside business hours, and the escalation path for a critical finding or a tester who triggers an incident. Review the list at each program review, since contacts change faster than policies do. The owner is the security operations manager, with HR or the service provider manager confirming that departed staff are removed.

Remediation routing record

This record shows where each finding went after the test, who was assigned, and when it was closed or accepted as a risk. Route findings into the same ticketing system used for vulnerability management so that owners, due dates and closure evidence are traceable. Check that every finding in the test report has a matching ticket and that risk acceptances name an approver. The vulnerability management or application security lead owns the routing, and system owners own the fixes.

Retrospective notes after each test

A retrospective records what the test covered, what the program got wrong (for example, scope gaps, delayed notifications or unclear rules), and what changes were made to the program document or the next test plan. Write it within a set period after the report is delivered and link it to the program version it changed. Assessors use these notes to confirm the program is improved, not just run. The program owner writes the note, and the testing lead and affected system owners review it.

Program review log

The review log shows the date the program was last reviewed, who reviewed it, what they checked and what changed. Keep one entry per review, including reviews that found no changes, so the gap between reviews is visible. Confirm the review interval is written in the program document and that the log matches it. The CISO or security governance lead owns the log, and the review itself should draw on the retrospectives and the escalation list.

What meeting Safeguard 18.1 costs in money and effort

This table lists each cost component of a Safeguard 18.1 penetration testing program, who is paid or who spends time on it, and whether it is one-time or recurring. Use it to scope a quote and to see which costs a self-hosted tool stack can reduce, while noting that no price is supplied for this safeguard.

Cost component	Who carries it	One-time or recurring	What drives it up or down
Drafting the program document	Internal security or compliance staff, with optional implementation partner help	One-time	Number of asset classes and test types in scope; existing policies that can be reused
Legal or risk review and approval	Legal, risk committee, executive sponsor	One-time, then on each material revision	Contract terms for third-party testers; how many approval layers the organization uses
Scope and limitations definition	Security lead, system owners, operations for acceptable test hours	One-time, then on scope changes	Number of networks, web applications, APIs, hosted services and physical premises covered
Contacts and remediation routing setup	Security operations, IT service owners, engineering managers	One-time, then on staff or team changes	Number of teams that own systems; clarity of the existing vulnerability remediation process
External tester or review partner time	Qualified external testing firm or consultant, if used	Recurring, tied to test cycles and scope updates	Size and complexity of scope; number of third parties involved; whether the partner also reviews the program document
Evidence upkeep and retrospectives	Security team, document owners	Recurring, at each test cycle and annual program review	Quality of finding records; whether test results and remediation status are tracked in one place
Assessor sampling and review	Internal audit, assessor or compliance team	Recurring, at each assessment cycle	Completeness of the documented program; availability of dated scope, approvals and retrospective records
Tooling for findings and evidence	Organization, through licenses or self-hosting effort	Recurring if commercial licenses apply	Open-source options can remove license spend for findings tracking and document control, though setup and hosting effort remains

Who writes, reviews and assesses the program

Your organization owns Safeguard 18.1. The program is an internal governance document, so the people accountable for security risk must decide what the program covers, how often tests run and who acts on the results. Approval should sit with someone who can accept residual risk, and the document should name the owner who keeps it current.

Program ownership: Name an accountable owner, usually in the security function, who maintains the document and answers assessor questions.
Scope and frequency decisions: Set which networks, web applications, APIs, hosted services and physical premises are in scope, and justify any exclusions.
Limitations and contacts: Record acceptable testing hours, excluded attack types and the people who must be told before and during a test.
Remediation routing: Decide which team receives findings, the severity thresholds that trigger action and how retrospectives feed back into the program.
Approval and review: Keep dated approval, version history and evidence that the program runs as written.

Before you rely on any partner draft, confirm that your own staff can explain every scope decision and limitation in the document.

How self-hosted open-source tools support the program record

A penetration testing program is only as useful as the record behind it, and self-hosted open-source tools can hold that record inside your own network. DefectDojo can import findings from penetration test reports and scanner output, either through its user interface or its API, and it supports more than 500 security tool report formats in the open source edition. It also offers a generic findings import for reports that do not match a known format. Its deduplication relies on per-tool hashcode fields, so the same weakness reported by two testers or two scans can be recognized as one finding instead of two. Confirm with your testers which report formats they deliver, and agree on a single import path before the first engagement. DefectDojo is licensed under BSD-3-Clause, which permits modification and redistribution with the license notice retained, so review the terms with your legal team before you build internal changes into it.

Greenbone Community Edition, built on OpenVAS, covers the scanning side that often sits alongside manual penetration tests. Its gvmd component stores results in PostgreSQL, manages users and permissions, and schedules scan tasks, while analysts review results in the Greenbone Security Assistant web interface. That gives you a dated scan history that can show the scope and frequency your program sets under Safeguard 18.1, provided the schedules match the documented program. The license is AGPL-3.0-or-later, and the AGPL has network-use terms that apply if you modify the software and make it available to users over a network. Ask your counsel whether any internal modifications or hosted access for contractors trigger those obligations. Greenbone's scans do not replace the qualified human testing the program requires, and automated results still need triage.

The program document itself, with its scope, limitations, contacts, remediation routing and retrospective requirements, can be held in XWiki or BookStack so changes are traceable. XWiki keeps every change under version control, recording what changed, when and by whom, and lets reviewers compare any two versions and roll back. XWiki is licensed under LGPL-2.1-or-later. BookStack, licensed under MIT, assigns user abilities through roles and lets you override permissions per role at the shelf, book, chapter or page level, which is useful for restricting edit rights on the program while keeping it readable to the testing team. Decide which tool you will use for the record and state that choice in the program document. Neither platform produces the program or validates that it is sufficient, so the content and approval still come from your organization.

Where organizations usually fall short on Safeguard 18.1

A penetration testing program under Safeguard 18.1 is judged on its written components, not on how many tests were run. The gaps below show where documentation, ownership and follow-through usually break down, and each card ends with a check to run against your own program.

Program exists only as practice

Testing happens each year, but no document states the program's purpose, owner or rules. The CIS Controls Assessment Specification scores Safeguard 18.1 on documentation, and an enterprise with no penetration testing program documentation receives a failing score. Assessors ask for the written program first, then for the tests that prove it operates. Action: write a one-page program charter and get it approved by a named executive before the next test.

Limitations and excluded attacks missing

Programs often state that testing will happen without defining what testers may not do. Safeguard 18.1 expects limitations such as acceptable testing hours and excluded attack types, such as denial of service against production systems or social engineering of specific staff. Without them, testers and operations teams make rules on the fly, and an outage during a test becomes a dispute. Action: list permitted hours, prohibited attack types and systems that are out of bounds, and have the system owner sign each one.

No named emergency contacts

A test can trigger alerts, block accounts or disrupt a service, and the people who must stop it are often unknown to the testing firm. Safeguard 18.1 asks for points of contact as part of the program. Missing contacts mean a tester keeps running while the security operations center waits for a call that nobody expected. Action: name a primary and backup contact for the testing team, the operations on-call team and the business owner of each in-scope system, with a tested stop procedure.

Remediation routing disconnected

Findings from a penetration test often land in a report that goes to a manager and stops there. Safeguard 18.1 requires remediation routing as a program characteristic, and it should connect to the vulnerability management process that Control 7 already defines. When routing is separate, findings get tracked in two places, or not at all. Action: confirm which ticket queue receives each finding, who assigns it, and that it follows the same severity and timeline rules as scanner results.

No retrospective step

Many programs end when the report is delivered. Safeguard 18.1 includes retrospective requirements, meaning a documented review of what the test found, what the program missed and what changes to scope, frequency or rules follow. Without a retrospective, the same blind spots recur from one test to the next. Action: hold a short review within a fixed period after each test and record decisions in the program document.

Document not reviewed after changes

The program document is written once, then the environment changes. New cloud accounts, acquired systems, new APIs or a changed hosting provider can fall outside the stated scope while the document still describes the old estate. Scope, frequency and contacts all drift. Action: set a review trigger for each major infrastructure change and a scheduled annual review, and record the approval date and version of the document.

Questions buyers ask about Safeguard 18.1

Does an IG1 organization need to meet Safeguard 18.1?

No. Safeguard 18.1 is assigned to Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1 organizations. IG1 covers essential cyber hygiene and is the minimum standard for every enterprise, and CIS places the penetration testing program later in the sequence. An IG1 organization that wants to test its defenses early can still write a simple program document, but no assessor will expect it under this safeguard. Confirm your Implementation Group against the CIS Implementation Groups pages before you scope the work, since your group determines which Safeguards you are measured against.

How long does it take to write a penetration testing program document?

The duration depends on the scope of the program and how many approvals it needs, so there is no fixed number to plan around. The work usually grows with the number of networks, web applications, APIs, hosted services and physical premise controls the program covers, and with the number of teams that must agree on contacts, acceptable testing hours and remediation routing. Ask any partner for a written timeline tied to a written scope, and ask which approvals sit on the critical path, such as legal, operations and the owners of hosted services. Do not accept a duration that is not tied to those inputs.

Can our own team write the penetration testing program without an outside partner?

Yes. Safeguard 18.1 is a documentation requirement, and the CIS Controls Assessment Specification scores it on whether the program documentation contains the minimum components, so an internal team can produce it. Assign a named owner who is accountable for the program, then have security, IT operations, legal and the owners of the systems in scope review the draft. Keep a record of who approved each section and when. A partner can help with structure, review or the technical detail of scope, but the organization owns the program and its contents.

What does the work need from our staff?

Staff time goes into four areas: naming the owner and the reviewers, listing the assets and services that testing may touch, agreeing limits such as acceptable hours and excluded attack types, and documenting who receives findings and how they route into remediation. Security leads usually draft the document, system owners confirm scope and boundaries, and operations or legal confirm limits that could affect production or contracts. Plan for review cycles, because each reviewer may raise changes to scope or limitations. Ask any partner to list these roles and their expected involvement in the written scope so you can assign people before work starts.

What drives the effort and cost of this safeguard?

Effort rises with the size and complexity of the enterprise, the number of systems and hosted services in scope, the number of business units and third parties involved, and how many approval steps the document must pass. Regulated environments with sensitive data and external providers usually need more review and more detailed limitations than a single-site organization. Costs fall into two groups: internal staff time, which is largely one-time for the first version and recurs when the program is reviewed, and any external help, which is paid for by the written scope. When requesting a quote, ask what is in scope, which approvals the partner expects, what the partner needs from your staff, and what review and update work is included after delivery.

Will an assessor test the penetration testing program itself or only the document?

Under the CIS Controls Assessment Specification, the measure for Safeguard 18.1 is the completeness of the program documentation, so the assessor checks whether the minimum components are present in the written program. An enterprise with no program documentation receives a failing score. The assessment specification does not list prerequisite safeguards for this measure. Assessors who work from the CIS Controls may also ask how the documented program is used in practice, such as whether tests have been run under it, so keep the approvals, scope records and retrospectives that show the program operates. Only an independent assessor or auditor can issue a result, and the organization should confirm with that party what evidence it expects.

How DeployOpen prepares the program and its evidence

DeployOpen plans, implements and documents the systems that support a penetration testing program for Safeguard 18.1 inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. That work covers the program document itself, the scope definition, the test rules and limitations, the contact and remediation routing, and the retrospective process, along with the records that show each element is in place. DeployOpen prepares this material and the evidence behind it. It does not issue assessment reports, attestations or certifications. Any statement that your program meets the CIS Controls Assessment Specification comes from your own review or from an independent assessor you engage.

Every engagement is fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, so you can see which program components are included, which are your responsibility, and which records your assessor will expect to find. A quote follows from that written scope. DeployOpen does not publish a price list, so the fastest way to compare options is to ask each provider for a written scope against the same list of program components. Ask what is one-time work, such as drafting the program document and configuring the evidence repository, and what recurs, such as annual reviews and test cycles.

Penetration testing programs need upkeep after the first document is approved. Scope changes when new systems go live, and contacts and limitations change with staffing. DeployOpen offers ongoing testing and support as retainers, which can cover keeping the program document current, maintaining the findings records and running retrospectives. Before you sign, confirm with any provider which of these tasks sit inside the retainer, who signs off on scope changes, and how quickly the written record is updated after a test.

Safeguard 18.1 Penetration testing program