Safeguard 16.13: Conduct Application Penetration Testing

To meet the safeguard 16.13: conduct application penetration testing requirement, you must run penetration tests against in-scope applications on a defined cadence and after meaningful change, then track remediation to closure with proof. Operationalize it by scoping apps, setting rules of engagement, using qualified testers, and retaining reports, tickets, and retest results. ¹

Key takeaways:

• Define “in-scope applications” and test triggers (release, major change, new exposure), then document the cadence and ownership. ¹
• Treat pen test findings as tracked risk: prioritize, fix, verify by retest, and record accepted risk with approvals. ²
• Evidence wins audits: scope, RoE, test plan, report, remediation tickets, retest/closure, and executive exceptions. ¹

Safeguard 16.13 expects you to validate that your applications can withstand real attacker techniques, not just pass automated scans. The practical outcome is repeatable application penetration testing that is scoped, authorized, executed by qualified resources, and tied directly to remediation and verification. ¹

For a CCO, Compliance Officer, or GRC lead, the fastest path is to turn 16.13 into a small operating program: a written standard, a living list of in-scope apps, clear triggers for when testing must happen, and a workflow that forces findings into engineering backlogs until closure. If your organization already runs SAST/DAST, keep them, but do not confuse them with penetration testing. A pen test is an adversarial exercise that chains weaknesses, tests authorization boundaries, and confirms exploitability and impact in context.

This page gives requirement-level implementation guidance you can hand to security and engineering leadership and then audit against. It focuses on execution, evidence, and common failure modes: unclear scope, “one-and-done” tests, non-actionable reports, and missing retest proof.

Regulatory text

Framework requirement: “CIS Controls v8 safeguard 16.13 implementation expectation (Conduct Application Penetration Testing).” ¹

Operator interpretation: You need a documented, repeatable practice to penetration test applications that matter to your risk profile, perform those tests as planned (and when changes warrant), and retain evidence that findings were triaged, remediated, and verified. The control is not satisfied by having a policy alone, or by running only vulnerability scanning. ²

Plain-English interpretation (what 16.13 means in practice)

Penetration testing for applications means authorizing a tester to act like a real attacker against a defined target application and environment, using realistic techniques to identify exploitable weaknesses and business impact. Your compliance outcome is simple: applications are tested, results are tracked, fixes are validated, and exceptions are governed. ¹

A good 16.13 implementation answers, with evidence:

• Which applications must be tested, and why.
• When testing happens (events and cadence).
• Who can perform testing and under what rules.
• How you ensure findings get fixed, not filed.
• How you verify closure (retest) and manage residual risk. ²

Who it applies to (entity and operational context)

Entity types: Enterprises and technology organizations adopting CIS Controls v8. ¹

Operationally, it applies where you have:

• Customer-facing web apps, mobile apps, APIs, SaaS platforms, or internal “tier 0” apps (identity, admin portals).
• Material business workflows implemented in code (payments, claims, trading, onboarding, HR/payroll).
• Internet exposure, third-party integrations, or sensitive data flows.
• Frequent releases where control drift is likely. ²

Common “in-scope” app categories

Category	Examples	Why it matters for 16.13
Internet-facing apps	marketing site with auth, customer portal	High likelihood of external attack paths
APIs	public partner APIs, mobile backend	Authorization and object-level access flaws
Admin interfaces	internal consoles, support tooling	Privilege abuse and lateral movement
High-data apps	PII/PHI/payment flows	Impact of compromise is higher
Third-party-hosted apps you configure	SaaS with custom logic, integrations	Misconfig and integration abuse paths

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

1) Define scope using an “application inventory view”

Start with an application list that includes owner, environment, exposure, data types, and change frequency. If you already have a CMDB or service catalog, add the missing fields rather than creating a parallel list.

Minimum fields to capture

• Application name and unique identifier
• Business owner and technical owner
• User types (customer, employee, admin)
• Entry points (web, mobile, API)
• Hosting model (on-prem, cloud, third party)
• Data classification touched
• External exposure (internet, partner-only, internal)
• Release/change pattern
• Last pen test date and status (planned/in-progress/complete)

Decision rule: If you cannot show a complete list of in-scope applications and their test status, audits stall because sampling becomes arbitrary. ¹

2) Set testing triggers and a documented cadence

Write a short standard that states when application penetration tests are required. Keep it enforceable.

Recommended triggers (write these into your standard)

• On a defined cadence for in-scope applications.
• After material changes (major feature changes, auth/role model changes, new integration, new internet exposure).
• Before go-live for new high-risk applications.

Avoid a standard that only says “regularly.” Examiners will ask “regularly means what, for which apps, approved by whom?”

3) Establish rules of engagement (RoE) and pre-approvals

RoE is the control point that prevents unauthorized testing and production outages, and it proves that testing was sanctioned.

RoE contents

• Targets (domains, IPs, app modules, APIs)
• Environments permitted (prod vs staging)
• Time windows, rate limits, and safety constraints
• Test accounts/roles provided (user, admin, support)
• Data handling rules for any captured data
• Allowed techniques and prohibited actions (for example, no DoS)
• Incident communications plan (who to page if instability occurs)
• Approval signatures (app owner, security, operations)

4) Choose tester qualifications and independence model

Pick an execution model that fits your maturity:

• External third party pen test firm: stronger independence; ensure contract covers retest and reporting format.
• Internal red team / appsec team: faster iteration; requires separation of duties and documented competence.
• Hybrid: internal pre-test plus external validation for highest-risk apps.

What matters for 16.13 is that the tester can perform real application exploitation and you can show consistent methodology and reporting. ¹

5) Execute the test with a risk-based focus

Ensure testing covers the attack surface that actually fails in real incidents:

• Authentication and session handling
• Authorization (role-based access, object-level authorization)
• Input handling and injection paths
• Business logic abuse (workflow bypass, pricing/quantity manipulation)
• API security (authZ, rate limiting behavior, data exposure)
• Secrets handling and sensitive data exposure
• Misconfiguration in app-adjacent components (WAF rules, headers, CORS where relevant)

You don’t need to document every payload for compliance, but you do need a report that ties findings to business impact and clear remediation guidance. ²

6) Intake findings into a remediation workflow (tickets, SLAs, owners)

Treat the pen test report as a work intake artifact, not a PDF that dies in a shared drive.

Operational minimum

• Each finding becomes a tracked item (ticket) with:
  • severity/priority (your scheme is fine if consistent)
  • owner (team or engineer)
  • due date (or documented rationale if deferred)
  • linkage back to the report section
• A triage meeting or async review with Security + Engineering + App Owner
• A documented exception process for accepted risk

7) Retest and closure verification

16.13 is weak without retest evidence. Require proof that fixes worked.

Retest options

• Targeted retest by the original tester
• Internal validation by appsec with documented steps and screenshots/logs
• Automated regression checks where feasible (as supplemental evidence)

Close the loop by updating the application inventory record (last tested date, open findings count, exception references). ¹

Required evidence and artifacts to retain

Keep artifacts in a system that supports access control and retention (GRC tool, ticketing system, secured repository).

Evidence checklist (auditor-ready)

• Application scope list / inventory view showing which apps require pen testing and current status
• Pen test standard (cadence + triggers) approved by Security leadership
• Rules of engagement + approvals for each engagement
• Engagement plan or statement of work (internal or third party)
• Final pen test report (with unique identifier/date/version)
• Raw notes are optional; final report is required for governance
• Remediation tickets mapped to findings (IDs referenced in report or in a mapping table)
• Retest results and closure evidence (retest memo, updated report, or validation record)
• Exception/accepted risk records with approvals and expiration/review date
• Management reporting: summary of testing completed vs planned, and overdue remediation items ²

Common exam/audit questions and hangups

Expect these in a CIS Controls assessment, customer due diligence, or internal audit:

1. “Show me your in-scope applications and the last test date for each.”
2. “What triggers an out-of-cycle pen test?”
3. “How do you ensure pen test findings are fixed?” (They will ask for ticket evidence, not verbal assurance.)
4. “How do you handle exceptions?” (Look for documented approvals and revisit dates.)
5. “How do you confirm a vulnerability is truly remediated?” (Retest proof.)
6. “Do you test APIs and mobile backends, or only the web UI?”

Hangup pattern: teams provide a single report for one flagship app, but cannot demonstrate a program across the application portfolio. ¹

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Confusing DAST/SAST with penetration testing.
Fix: keep scanners, but maintain a separate pen test requirement and evidence stream.

Mistake 2: No documented scope, so testing is ad hoc.
Fix: publish an application scope rule tied to exposure and data sensitivity, and keep a living inventory.

Mistake 3: Reports without remediation tracking.
Fix: require ticket IDs in the report deliverable, or create a finding-to-ticket mapping within a week of report delivery.

Mistake 4: “We fixed it” with no retest.
Fix: define closure criteria that includes retest evidence for high-impact findings.

Mistake 5: Third-party pen test cannot test real roles or workflows.
Fix: provision test accounts across roles, include business logic in scope, and add a pre-engagement walkthrough with app owners.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard, so you should treat 16.13 as a framework expectation rather than a standalone legal requirement with cited penalties. ¹ The risk is still concrete: weak application security testing increases the chance that authZ flaws, business logic abuse, and chained exploits persist into production, where they often bypass perimeter controls.

A practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign ownership: AppSec (execution) and GRC (governance and evidence).
• Draft and approve the pen test standard: scope criteria, triggers, minimum report requirements, retest expectation. ¹
• Build the initial in-scope application inventory view and identify top-risk apps (internet-facing, sensitive data, admin).
• Pick execution model (internal, external third party, hybrid) and prepare a reusable RoE template.

Days 31–60 (run tests and prove the workflow)

• Run at least one full engagement end-to-end on a high-risk application: RoE approvals, testing, reporting, ticketing, triage.
• Establish a consistent severity taxonomy and remediation workflow in your ticketing system.
• Implement the evidence binder structure (repository + naming conventions + access controls).
• Define retest mechanics: who does it, what counts as proof, and how closure is recorded.

Days 61–90 (scale across the portfolio)

• Expand testing to additional in-scope applications based on exposure and change rate.
• Add a lightweight governance cadence: monthly status review with overdue remediation and exceptions.
• Create management reporting that ties “planned vs completed” testing and “open findings vs closed” by application.
• If you use Daydream for control operations, map safeguard 16.13 to a documented control procedure and schedule recurring evidence capture so audits pull from one place, not email threads. ²

Frequently Asked Questions

Do we need to penetration test every application?

You need a defined scope rule and a documented list of in-scope applications, then test those consistently. Use exposure, data sensitivity, and business criticality to set scope, and keep the rationale in your inventory. ¹

Can an internal team perform the application pen test?

Yes, if you can show competence, consistent methodology, and governance that avoids “marking your own homework” for high-risk apps. Many organizations use internal testing for coverage and a third party for validation on the riskiest targets. ²

Is a vulnerability scan (DAST) enough to satisfy 16.13?

A scan supports application security, but it is not the same as a penetration test. Keep scan results as supplemental evidence, and keep pen testing as a distinct activity with its own report, findings, and retest proof. ¹

What evidence do auditors usually reject?

A PDF report without proof of remediation and closure often fails because it does not demonstrate control operation. Missing scope (which apps, which environments) and missing approvals (RoE) also trigger findings. ²

How should we handle production testing risk?

Use RoE constraints: time windows, rate limits, safe testing techniques, and a comms plan with operations. If you prohibit production testing, document that policy and ensure staging mirrors production enough for results to be meaningful.

How do we manage accepted risk for findings we can’t fix quickly?

Record an exception with business owner approval, security sign-off, a compensating control if available, and a review/expiration point. Keep the exception linked to the original finding and track it like any other risk item. ¹

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8