Safeguard 16.13 Application penetration testing: evidence and audit

What Safeguard 16.13 application penetration testing asks for

If you must show CIS Control 16 coverage, start with this: Safeguard 16.13 asks for application penetration testing, and it applies only in Implementation Group 3. Organizations in IG1 and IG2 are not required to meet it under the CIS Controls, though many run application testing anyway. The Software asset class and the Detect security function place it in the application layer of your program. In the CIS Controls Assessment Specification, the measurement starts with Safeguard 2.1, a software inventory, so you cannot prove coverage for applications you have not listed. Confirm the exact wording and metrics in the CIS Controls Assessment Specification for Safeguard 16.13 before you write your evidence plan.

The reason this safeguard exists is that automated scanners and code analysis tools match known patterns. They find missing patches, injection signatures and insecure configurations well. They are weak at business logic flaws, such as a discount that can be stacked indefinitely, an approval step that can be skipped by changing an identifier, or a workflow that lets a low-privilege user reach another customer's records. CIS states that for critical applications, authenticated penetration testing is better suited to these flaws, with testers acting as both authenticated and unauthenticated users. That means your testers need test accounts for each role, documented role matrices and enough time to walk the workflows, not just a scan with credentials.

Application penetration testing sits beside Control 18, which covers the enterprise-wide testing program. Control 18 looks at people, processes and technology across the environment, while 16.13 looks at the applications your developers build, host or acquire. In practice, one program can serve both, but the scope, test accounts and findings should stay traceable to individual applications. The hard parts are usually organizational: deciding which applications count as critical, keeping the software inventory current enough to show every application was considered, and tracking each finding through remediation with an owner and a due date. Ask your team to name the critical application list, its owner and the date it was last reviewed before you schedule any testing.

Which applications and teams fall under 16.13

Safeguard 16.13 is only as complete as the list of applications it covers. The cards below cover the scoping decisions that determine which applications, interfaces and teams must go through application penetration testing, and the inputs that make those decisions defensible.

Defining critical applications

The CIS Assessment Specification scores authenticated testing only against critical applications, so the enterprise must define that term in its own process. Criticality usually follows business impact: applications that process sensitive data, carry payments or patient records, support regulated services, or whose outage or compromise would stop operations. Document the criteria, the owner who applies them, and the list that results. An auditor will ask how the list was produced, so the reasoning matters as much as the list.

In-house, hosted and acquired software

Safeguard 16.13 sits within the software life cycle that Control 16 describes, which covers software built in-house, hosted by the enterprise, and acquired from vendors. Each category needs an owner for testing. In-house code is usually tested by the enterprise or its partner. Vendor products may restrict testing, so the contract or the vendor's permitted testing terms should be checked before scope is fixed. Record which category each application falls into.

APIs and cloud-hosted services

Many critical applications expose APIs, microservices and cloud-hosted components that users never see in a browser. Business logic flaws often sit in those interfaces, such as authorization checks on object identifiers or workflow steps that can be skipped. Scope should list each externally reachable API and each cloud service that the application depends on, along with the accounts and environments where testing is permitted. Confirm cloud provider testing rules before scope is agreed.

The Safeguard 2.1 software inventory

The assessment specification lists Safeguard 2.1, the software inventory, as a prerequisite for measuring Safeguard 16.13. Without it, the enterprise cannot show which applications exist, so the coverage metrics have no reliable denominator. Check that the inventory records each application's owner, hosting location, criticality and version. Applications missing from the inventory are the most likely source of untested exposure during an assessment.

IG3 tier and regulated assets

Safeguard 16.13 is assigned to Implementation Group 3 only. An enterprise that has not reached IG3 may still choose to test applications, but a formal IG3 measurement depends on its tier and on whether it holds regulated or sensitive assets facing sophisticated attacks. Confirm the IG tier with the enterprise's risk owner before setting scope, because it determines which applications and teams the assessment will expect to see covered.

Teams that own the scope

Scope spans several teams: application owners who set criticality, development teams who fix findings, platform teams who host environments, and security teams who run the testing and track results. Name one accountable owner for each in-scope application and record who approves exclusions. Scope decisions made by one team alone often miss applications another team quietly runs, so the list should be reviewed with development and operations leads.

How an assessor tests Safeguard 16.13

This table shows how an assessor works through Safeguard 16.13 under the CIS assessment specification, from the two coverage metrics to the evidence requested and the findings that usually cause a failing or weak score. Read it as a checklist of what to have ready before an assessment begins, since most gaps come from missing records rather than from testing quality.

Assessment element	What the assessor looks for	Common gap
Gating question	Whether the enterprise has an application penetration testing process at all. If none exists, the Safeguard receives a failing score regardless of other results.	No written process, or testing happens only ad hoc after a incident or customer request.
Unauthenticated coverage metric	The share of applications that underwent unauthenticated penetration testing under the enterprise's own documented process.	The application inventory is incomplete, so the denominator is understated or disputed.
Authenticated coverage metric	The share of critical applications that underwent authenticated testing, with testers working as both authenticated and unauthenticated users.	Critical applications are not classified, so it is unclear which ones count.
Prerequisite inventory	A software inventory under Safeguard 2.1 that lets the assessor confirm which applications exist and which are critical.	Shadow or SaaS applications are missing, so untested apps never appear in the count.
Test plans and scope lists	Documents that state which applications were in scope, the test type, the testing window and the testers' access levels.	Scope lists copied forward from a prior year that no longer match the current application estate.
Test reports	Dated reports showing findings, including business logic issues, tested roles and the methods used.	Reports cover only automated scan output, which an assessor may not accept as authenticated penetration testing.
Retest and closure records	Evidence that findings were validated after remediation and that the retest matched the original scope.	Findings are marked closed without a retest, or retests cover only some of the original issues.
Common finding: stale scope	Scope lists that exclude applications added or changed since the last test.	Major releases or new APIs ship without being added to the testing plan.
Common finding: untested critical apps	Critical applications with no authenticated test in the review period.	Business-critical internal tools are treated as low priority and fall outside the test cycle.

How to implement 16.13 in sequence

The sequence turns Safeguard 16.13 from a one-time test into a repeatable process: it starts from a known application inventory, sets the scope of critical applications, and produces a penetration testing record that an assessor can trace from scope to retest. Each step names the output that lets the next step begin.

Confirm the software inventory under 2.1
Start by checking that the organization has an up-to-date software inventory under Safeguard 2.1, which the CIS Controls Assessment Specification lists as a prerequisite for measuring 16.13. The security or platform team owns this check, and the inventory should name each application, its owner, where it runs and whether it is in-house, hosted or acquired. Output: a reviewed application list that becomes the population for every later step. If the inventory is missing applications, the coverage metric cannot be calculated honestly, so resolve gaps before scoping.
Classify critical applications
Using the reviewed inventory, the application owner and business stakeholders mark which applications are critical, meaning those whose compromise would materially affect customers, regulated data or core operations. Record the criteria in writing so the classification can be explained to an assessor. Output: a critical application register with the reason for each entry and a named owner. This register is the denominator for the Authenticated Penetration Testing Coverage metric, so it must be stable and reviewed when applications change.
Define the penetration testing process and cadence
Write the application penetration testing process the assessor will read: which applications are in scope, who performs the tests, the testing methods, how findings are rated, who approves retests and how often testing repeats. The CIS Controls Assessment Specification scores the safeguard against the enterprise's own process, so the document must be specific. Confirm the testing cadence with the organization's leadership and any regulatory obligations, since this page does not supply a required frequency. Output: an approved process document with a named owner and a scope rule for new or changed applications.
Run unauthenticated tests on the application population
Testers attack the applications from outside, without valid credentials, to find exposed endpoints, misconfigured handling of unauthenticated requests and common weaknesses. The security team or an independent tester runs these tests against the agreed scope, ideally in a non-production environment that mirrors production or against production under agreed rules of engagement. Output: a dated test record for each application in scope that feeds the Unauthenticated Penetration Testing Coverage metric, with the tester's method and the scope tested.
Run authenticated tests on critical applications
For each critical application, testers log in with the roles real users hold and then act as both authenticated and unauthenticated users, probing business logic such as workflow steps, pricing, approvals and access between user roles. CIS states that this form of testing is better suited than code scanning and automated testing to finding business logic vulnerabilities. Output: a test record per critical application showing which roles were used, which workflows were exercised and which findings were raised, which feeds the Authenticated Penetration Testing Coverage metric.
Track findings to remediation
Log every finding in a tracking system with an owner, a severity rating from the organization's vulnerability rating process and a target date set by that process. Development teams fix the issue, and the security team confirms the fix against the original finding. Tools such as DefectDojo can import and deduplicate findings from many test tools, which helps keep one record per issue. Output: a findings register showing status for each issue, with closed items linked to the fix that resolved them.
Retest and close the cycle
Once fixes are deployed, the same testers or an independent team retest the affected functions, including the authenticated paths for critical applications, to confirm the defect is gone and has not reappeared in a related workflow. The security lead records the outcome and decides whether the cycle is closed or needs another round. Output: retest evidence attached to each closed finding and a cycle summary that shows scope, coverage and open items. The summary becomes the input for the next planning cycle, starting again at the inventory check.

Why authenticated testing finds business logic flaws

Business logic flaws only appear once a user is logged in and an application is doing what the business designed it to do. Consider an illustrative online procurement portal where a buyer role can approve purchase orders up to a set limit, and a manager role can approve above it. A flaw might let a buyer submit an order, then edit the approved quantity after approval, so the total slips under the approval threshold. Each request is valid on its own, the code has no obvious injection point, and no single step looks wrong. Code scanning reads the source for known insecure patterns and cannot judge whether a role should be allowed to perform a sequence of actions. Automated scanners that crawl without credentials see only the pages a visitor can reach, so the post-login workflow, role boundaries and price or limit logic often go untested.

CIS states that for critical applications, authenticated penetration testing is better suited than code scanning and automated testing to finding business logic vulnerabilities. The practical change is in who the tester is pretending to be. A tester working as an unauthenticated user checks what an outsider can reach, such as login flows, password reset, and exposed endpoints. A tester working as an authenticated user, ideally holding each role the application offers, checks what a legitimate account can do that it should not. Testing as both gives two views of the same application, and the coverage metric in Safeguard 16.13 only counts critical applications tested in the authenticated mode, so an enterprise that tests only from outside will not show authenticated coverage.

Before commissioning this work, confirm three things with the testing provider and your application owners: which roles and test accounts will be provided, what business rules each role is expected to respect, and which workflows touch money, limits or privileged actions. Written rules give the tester a baseline to test against. Ask the provider to state in the scope which role pairs will be tested against each other, such as a buyer attempting manager actions, and to record the test accounts used. Those records also become evidence that the authenticated testing happened as a defined activity rather than an ad hoc exercise.

Evidence that passes a 16.13 review

An assessor testing Safeguard 16.13 looks for a documented process and proof that it runs, not a single test report. The artifacts below form a chain: the process defines the register, the register drives scope, scope produces findings, and findings close through retest. Each link must stay current between annual cycles.

Written penetration testing process

The governing document sets how applications are selected for testing, who runs the tests, how authenticated and unauthenticated tests differ, how findings are rated and how retesting is confirmed. The CIS Controls Assessment Specification scores 16.13 as failing when no application penetration testing process exists, so this is the first artifact to show. Check that it names an owner, a review date and the approval record. Confirm that it covers both unauthenticated and authenticated testing for critical applications.

Critical application register

The register lists which applications the enterprise treats as critical, with business owner, data sensitivity, internet exposure and the date of the last authenticated test. The authenticated coverage metric depends on this list, so an incomplete register inflates the apparent share of critical applications tested. Use the software inventory from Safeguard 2.1 as the source so no internally hosted or acquired application is missing. Review the register whenever a new application goes live or an existing one changes its data or user population.

Scope and test plans per application

Each critical application needs a written scope that names its environments, user roles and accounts supplied to testers, and the business logic the test must exercise, such as payment limits, approval chains and account recovery. Test plans record the methods used and any restrictions agreed with the application owner. Without role-specific accounts, an authenticated test cannot show whether one user can reach another user's data. Keep plans versioned so a retest can be compared against the scope it originally covered.

Tester qualifications and independence

Assessors ask who performed each test and whether they were independent of the team that built the application. Keep records of tester training, certifications or demonstrated experience, and a signed rules-of-engagement document for each engagement. Internal testers and external firms both need this evidence. Confirm that testers used the same account roles the application's real users hold, so that business logic findings reflect actual access rights.

Penetration test reports and findings

Each report should state the application, version, test dates, tester identity, methods, the unauthenticated or authenticated mode used, and every finding with severity, reproduction steps and affected components. Business logic findings often appear only in authenticated reports, so a report without a logged-in test section does not satisfy the critical application requirement. Store reports in a system that keeps them read-only once issued, and track which findings came from scanners and which from manual testing.

Remediation tickets and retest evidence

A finding is closed only when a ticket shows the fix, the owner, the due date against the severity rating, and a retest that confirms the fix worked. Assessors sample tickets to see whether high-severity issues were closed on time and whether retests were performed by someone other than the fixer where practical. Link each ticket back to its report and finding identifier so the chain can be traced in both directions. Open-source tracking tools such as DefectDojo can hold this chain if their import and deduplication settings are reviewed.

What meeting Safeguard 16.13 costs

This table breaks down the cost components of meeting Safeguard 16.13, who is paid for each, whether it is one-time or recurring, and what drives it up. No dollar figures are given because none are sourced for this Safeguard, so use the table to build a line-item quote request. Read the recurring rows as the costs that continue after the first test cycle.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
External tester fees	Independent penetration testing firm or consultant	Recurring per test cycle	Number of in-scope applications, depth of authenticated testing, and number of test rounds
Internal tester time	Your security staff or engineers who support the test	Recurring per test cycle	Access setup, scoping meetings, and how many teams own the applications
Test accounts and role setup	Your application or identity engineers	One-time, then updated as roles change	Number of user roles, authentication method, and MFA or SSO complexity
Supporting open-source tooling	Your team or an implementation partner for self-hosted deployment	One-time setup, recurring upkeep	Choice of tools such as DefectDojo for tracking findings and Greenbone for network-level scanning, plus hosting and maintenance
Remediation engineering	Your development teams	Recurring per finding cycle	Number and severity of business logic and authorization flaws found, and whether the Safeguard 16.2 and 16.3 processes are in place
Retesting	External tester or your internal testers	Recurring after each fix round	Number of confirmed findings and whether retests are scoped in the original quote
Evidence upkeep	Your compliance or security lead	Recurring	Retention of reports, scope records, and remediation tickets, and how they link to the software inventory from Safeguard 2.1
Assessor sampling	Your staff during an independent audit, and the auditor's own fees	Recurring at each assessment	Number of applications sampled and how quickly test records can be produced
Written process development	Your security function, with optional outside help	One-time, then reviewed	Whether a documented penetration testing process already exists, which the assessment specification checks for a passing score

Open-source tools that support 16.13 evidence

The CIS Controls Assessment Specification lists Safeguard 2.1, the software inventory, as a prerequisite for measuring 16.13. Two open-source tools can tie that inventory to known vulnerabilities on hosts, which helps teams decide what belongs in penetration test scope.

Wazuh vulnerability detection (GPL-2.0-only): Agents collect software inventories from monitored endpoints, and Wazuh correlates them with the Wazuh CTI vulnerability repository or a locally hosted offline copy to identify vulnerabilities in the operating system and installed applications.
Offline operation: Teams in restricted networks should confirm how the offline copy is updated and approved under their change process before relying on it.
Fleet (MIT): Fleet matches software installed on enrolled hosts against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV.
Source coverage: Check which advisory sources apply to each operating system in scope, since coverage varies by platform.

Confirm that every host and application hosting a critical application appears in the inventory, because the scope of 16.13 testing depends on it. For details on the Wazuh approach, see the Wazuh vulnerability detection documentation.

Where organizations fall short on 16.13

Most shortfalls against Safeguard 16.13 are not about running a test. They come from missing process, untested coverage of critical applications, and evidence that cannot be assembled when an assessor asks for it. Each card below names one gap, why it fails the measurement, and the check to run before the next assessment.

No defined penetration testing process

The CIS Controls Assessment Specification scores Safeguard 16.13 as failing if the enterprise has no application penetration testing process. Many teams run occasional tests after a release or a customer request, but nothing states when testing happens, who approves scope, which applications are in it, or what happens to findings. Ask whether a written process exists, names an owner, and sets triggers such as major releases, new internet-facing applications and significant architecture changes. Close the gap by writing and approving the process before scheduling the next test.

Only unauthenticated testing

The Authenticated Penetration Testing Coverage metric measures the share of critical applications tested with valid user accounts. Testing that only probes the login page and public endpoints misses what happens after sign-in, where most business logic sits, such as price changes, approval chains and tenant boundaries. The Safeguard notes that authenticated testing is better suited to finding business logic flaws, with testers acting as both authenticated and unauthenticated users. Check whether test accounts exist for each role and whether the scope covers them.

Critical applications never identified

Authenticated Penetration Testing Coverage is calculated against critical applications, so an enterprise that has not defined that category cannot show coverage. Application lists often exist in a CMDB or a spreadsheet that predates recent cloud and SaaS deployments. The Safeguard depends on Safeguard 2.1, the software inventory, so an incomplete inventory hides applications from both scope and measurement. Confirm the criteria for criticality, such as data sensitivity, transaction value or regulatory scope, and reconcile the list against the inventory each review cycle.

Findings closed without retest

A penetration test produces value only when fixes are verified. Teams often mark a finding resolved in the ticket tracker once the developer reports a patch, without a retest by the tester or an independent check. The Safeguard's metrics measure testing coverage, but assessors reviewing the process will look for evidence that results drive remediation. Ask for each finding a record of the fix, the retest date, the tester who validated it, and any risk accepted instead of fixed, with an approver's name.

Evidence scattered across tickets

Scope documents, rules of engagement, test accounts used, raw reports, remediation tickets and retest results often sit in different systems, owned by different people. When an assessor asks for proof that testing occurred on critical applications over the period, the team reconstructs the record by hand, and gaps appear. Centralizing findings in a single tracker with stable identifiers for each application and test lets the team export coverage per application. Confirm the tracker keeps the link between each test, each finding and each closure.

Questions buyers ask about Safeguard 16.13

How much does application penetration testing for Safeguard 16.13 cost?

No public price applies to this work, and the cost depends on the written scope. The main cost drivers are the number of applications in scope, how many of them are critical, whether testing is authenticated as well as unauthenticated, the number of user roles and workflows to test, the depth of retesting after fixes, and the state of the environments provided for testing. The organization pays for the testing service, for internal time spent preparing access and reviewing findings, and for remediation work that follows. Ask any provider for a quote that lists each application, each role and environment to be tested, the test types, the deliverables, and whether retesting is included. DeployOpen does not publish a price list and quotes from a written scope.

How long does it take to run the first application penetration test?

The timeline depends on the number of applications, their complexity and how quickly access and test accounts are provided. Before testing starts, the organization needs an agreed scope, a list of critical applications, and test environments that behave like production. Testing time grows with each application and each user role. Confirm the schedule, the testing window, and the retest period in the written scope before work begins. DeployOpen agrees scope, deliverables and timelines in writing before most engagements start.

What does the organization need to provide for application penetration testing?

The organization needs to supply several inputs:

A software inventory, because CIS lists Safeguard 2.1 as a prerequisite for measuring Safeguard 16.13
A documented application penetration testing process, since a missing process fails the Safeguard
A list of critical applications and the business functions they support
Test accounts for each user role, plus any documentation on workflows and business rules
A non-production environment that matches production closely enough to test realistically
Named staff who can answer questions, approve testing windows and act on findings

Without these inputs, testers spend time on discovery and the results are harder to compare across cycles.

Can we run application penetration testing in-house instead of hiring a provider?

Yes, the organization can run testing with its own staff if it has people with the skills and time to do it, and the Safeguard does not require an outside provider. The CIS Controls Assessment Specification measures whether a process exists and what share of applications and critical applications were tested under it, so the testers' identity is not the test. Check whether your team can perform authenticated testing across every role, document methods and results consistently, and retest fixes. An outside partner can help prepare systems and evidence, or perform testing under a fixed scope, but the organization still owns the process and its results.

How does authenticated application penetration testing differ from scanning?

Automated scanners and code analysis check for known patterns, while authenticated penetration testing finds flaws in how the application behaves. CIS states that for critical applications, authenticated penetration testing is better suited than code scanning and automated testing for finding business logic vulnerabilities, with testers acting as both authenticated and unauthenticated users. In practice, this means a tester logs in with each role, tries to skip approval steps, changes object identifiers to reach another user's data, and checks whether limits in the workflow hold. Scanning and penetration testing complement each other, so keep both in the program.

What will an auditor ask for to verify Safeguard 16.13?

An assessor will look for evidence that a written application penetration testing process exists and that it is followed. The CIS Controls Assessment Specification scores the Safeguard on two metrics: unauthenticated penetration testing coverage, which is the share of applications tested without credentials, and authenticated penetration testing coverage, which is the share of critical applications tested with credentials. Expect requests for the written process, the application inventory used to define scope, the test scope and reports for each cycle, records of authenticated test roles, and evidence that findings were tracked and retested. Confirm with your assessor which framework they are testing against, since the CIS Controls are not a certification scheme.

Which open-source tools help track application penetration testing findings?

Open-source tools do not perform authenticated business logic testing on their own, but they help manage the results. DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and deduplicates findings using per-tool hashcode fields. Wazuh and Fleet can help with the software inventory that defines scope, and Greenbone Community Edition (OpenVAS) covers vulnerability scanning in the same program. Confirm each tool's capabilities against its documentation before relying on it for evidence, and keep manual test reports as the primary record of authenticated testing.

Which ISO 27001 or PCI DSS controls map to application penetration testing?

The CIS Controls Navigator maps Safeguard 16.13 to ISO/IEC 27001:2022 Annex A controls 8.8 and 8.29, and to PCI DSS v4.0 requirement 6.2.4. Check the Navigator's current mappings before relying on them in a submission, because mappings are maintained by CIS and can change. Your assessor, not the mapping, decides whether your evidence satisfies each framework. Use the same test reports, scope records and remediation tracking to answer each framework's requests.

How DeployOpen prepares 16.13 evidence

DeployOpen prepares the systems, test scope and documentation that an organization needs to show Safeguard 16.13 Application penetration testing is in place. Testing runs against applications inside the client's own infrastructure, and the organization owns its penetration testing process and the conclusions drawn from it.

How we scope

Each engagement starts with a written scope that names the applications, environments and test types covered.
Critical applications are identified so authenticated testing with business logic focus can be planned for them.
Software inventory records are confirmed first, since the assessment specification treats Safeguard 2.1 as a prerequisite for 16.13.

How we build

Test accounts at each access level are prepared so testers can act as both authenticated and unauthenticated users.
Testing is planned against the documented application penetration testing process the organization has adopted.
Findings are recorded in a consistent format so coverage of unauthenticated and authenticated testing can be counted.

How we hand over

Deliverables include the test scope, methodology, findings and remediation status for each tested application.
Evidence is organized so an assessor can trace coverage metrics back to the applications tested and the process followed.
Documentation is handed over in the organization's own systems, and the organization decides how results feed its remediation workflow.

How we support

Fixed-scope engagements have deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Confirm with your independent assessor which evidence formats they accept before the engagement is scoped.