TL;DR: 84% of organizations suffered a cyberattack in 2024, yet only 26% pentest more than once a year and over 40% say results are stale before delivery, leaving modern environments exposed between point-in-time tests, according to Horizons.ai. Cadence now matters as much as coverage, because validation that arrives after the environment changes is not assurance.
At a glance
What this is: This article argues that annual and quarterly pentesting no longer matches modern attack speed, with most organisations facing stale results and long gaps between validated exposures.
Why it matters: For IAM, NHI, and broader security teams, the point is that control assurance must track change velocity, not calendar cycles, or blind spots persist between tests.
By the numbers:
- 84% of organizations suffered a cyberattack in 2024.
- 26% conduct pentests more than once annually.
- Over 40% say their pentest results are invalid by the time reports are delivered.
- 20% of CISOs admit they pentest only to meet compliance mandates.
Context
Pentesting is a control-validation method, not a control in itself. Its value depends on whether the test window overlaps with the period in which real attack paths exist, and that assumption weakens quickly in cloud, DevOps, and fast-changing hybrid environments.
The identity angle is indirect but real: when environments change daily, access paths, service accounts, and privileges can become exploitable long before the next scheduled assessment. The governance problem is not whether testing happens, but whether the cadence matches the pace at which exposure appears and disappears.
Key questions
Q: Why does annual pentesting fail in cloud and DevSecOps environments?
A: Annual pentesting assumes the environment stays stable long enough for a snapshot to remain meaningful. Cloud and DevSecOps workflows invalidate that assumption because new services, configuration drift, and inherited access can appear between assessments. The result is a report about a past state, not proof that the current state is safe.
Q: When should organisations prioritise continuous validation over point-in-time pen testing?
A: Prioritise continuous validation when code releases, infrastructure changes, or identity changes happen frequently enough that a quarterly test cannot keep pace. It is most useful when credentials, permissions, or business logic shift often, because those are the conditions where AI-assisted attackers can discover and exploit gaps faster than manual review cycles can respond.
Q: When does a pentest become too stale to be useful?
A: A pentest becomes stale when the tested configuration no longer resembles the live environment, especially after deployments, access changes, or infrastructure drift. If findings arrive after the environment has materially changed, the result is evidence of past risk rather than current assurance.
Q: How should security teams balance compliance testing with operational assurance?
A: Use compliance as the minimum baseline, then layer a risk-based internal schedule on top of it. High-change applications may need quarterly, monthly, or continuous assessment depending on release volume and sensitivity. The deciding factor is not the audit calendar but how quickly the environment changes and how costly missed exposure would be.
Technical breakdown
Why point-in-time pentesting creates blind spots
Point-in-time pentests assume the attack surface is relatively stable between tests. That model breaks when cloud assets, identities, and application changes are continuous. A finding verified on Monday can be obsolete by Friday if a new service, role, or trust path appears. The result is not just incomplete coverage, but misleading confidence, because reporting cadence starts to matter more than exposure cadence. In fast-moving environments, assurance has to be event-driven or continuous, not calendar-driven.
Practical implication: Treat scheduled pentests as snapshots and add trigger-based validation after material environment change.
How attack speed outpaces scheduled validation
Modern adversaries do not need months to exploit weak controls. In practice, rapid privilege escalation, weak segmentation, and exposed services can be chained into impact faster than many organisations can schedule remediation review. Automated offensive testing compresses the attacker simulation into minutes or hours, which is why long gaps between assessments are so dangerous. The technical issue is timing: if exploitation can happen inside the change window, annual testing cannot measure whether controls actually interrupt the attack path.
Practical implication: Tie test frequency to attacker dwell time and deployment velocity, not to compliance calendar cycles.
Continuous testing as an assurance model
Continuous pentesting shifts security validation from periodic certification to ongoing verification. Instead of waiting for a report cycle, teams use repeated attack-path simulation to see whether newly introduced weaknesses are exploitable now. This is especially relevant where machine identities, cloud permissions, and DevOps releases create fresh paths faster than manual review can keep up. The goal is to measure whether current exposure can be abused, not whether last quarter’s environment was hard to break.
Practical implication: Embed recurring exploit validation into change management and DevSecOps workflows.
Threat narrative
Attacker objective: The attacker aims to move from initial foothold to critical impact before the next scheduled pentest can reveal the path.
- Entry occurs through exposed or newly introduced weaknesses that appear between scheduled tests in rapidly changing environments.
- Escalation follows when attackers chain misconfigurations, weak privileges, or untested paths faster than periodic validation can detect them.
- Impact arrives before the next test cycle, leaving organisations with months of unmeasured exposure and stale assurance.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Annual pentesting has become a governance lag indicator, not an assurance model. The problem is not that testing is obsolete, but that the control assumption behind it is stale: that exposure changes slowly enough for periodic review to remain meaningful. In cloud and DevOps environments, that assumption fails because identities, configurations, and attack paths change faster than reporting cycles. Practitioners should treat pentest cadence as a risk variable, not a compliance ritual.
Exposure windows now matter more than test frequency alone. A test performed every quarter can still miss the period in which a new service account, network path, or application release becomes exploitable. That is a governance gap because it creates a false sense of control coverage. The practical conclusion is that security teams must align validation with change velocity, especially where NHI, cloud permissions, and automated deployments expand the attack surface continuously.
Continuous validation is the new baseline for environments that change daily. This is not a call to replace manual expertise, but to use repeated attack simulation where controls must be proven against current state. For identity-led environments, that means testing whether privilege, trust, and workload access are still defensible after every material change. The practitioner takeaway is straightforward: if the environment changes faster than the testing calendar, the calendar is the weak control.
Pentest cadence is now a board-level risk question, not only a security operations question. When over 40% of teams say results are stale on delivery, the issue becomes governance credibility as much as technical coverage. Organisations should be able to explain how often validated exposure is refreshed and why that interval is defensible for the business. The practitioner conclusion is to make test cadence part of risk governance and resilience reporting.
What this signals
Exposure freshness is now the metric that matters. Security teams should measure how long a pentest remains valid after delivery, because change velocity determines whether the result still reflects reality. In environments where identities, services, and network paths shift constantly, the useful question is not when the last test ran, but how current the assurance still is.
Continuous validation closes the governance gap left by calendar-based testing. Annual or quarterly cadence can satisfy compliance while still leaving long periods of unmeasured exposure. Practitioners should align validation with release events, cloud changes, and privilege changes so that assurance follows the environment rather than the audit schedule.
For practitioners
- Map pentest cadence to change velocity Set testing frequency based on release rate, cloud churn, and privilege change rather than annual compliance minimums.
- Add trigger-based retesting after material changes Retest when new applications, identities, network paths, or cloud services are introduced, because these are the moments exposure changes fastest.
- Use continuous validation for internet-facing and cloud assets Schedule repeated offensive checks for assets whose attack surface changes daily, including workloads, APIs, and externally reachable services.
- Separate compliance testing from assurance testing Keep annual manual pentests where required, but add more frequent exploit validation to measure current risk, not last quarter's state.
- Report exposure freshness as a governance metric Track how long validated findings remain current and show executives whether the security team is testing fast enough to keep pace with change.
Key takeaways
- Annual or quarterly pentesting can leave long exposure gaps when cloud, identity, and application changes happen faster than the next scheduled test.
- The article’s data shows a mismatch between attack speed and testing cadence, with stale results undermining point-in-time assurance.
- Security teams should treat pentest frequency as a governance decision tied to change velocity, not a fixed compliance interval.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0004; TA0006; TA0008 — Privilege Escalation; Credential Access; Lateral Movement | The article focuses on rapid attack progression through exploitable paths and privilege gain. |
| Recommendation — Map test coverage to privilege escalation and lateral movement paths, then retest after each material change. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | Pentesting here is about identifying exploitable weaknesses before attackers do. |
| PR.IR-01 — Networks and systems are protected | The article argues that protection has to be validated against live attack paths, not assumed from last test. | |
| Recommendation — Use recurring validation to keep vulnerability identification aligned with current environment state. Validate protective controls continuously where deployment velocity changes the attack surface. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Frequent testing and retesting are central to the article's recommended operating model. |
| Recommendation — Adopt continuous vulnerability validation and retest critical exposures after each change. | ||
| NIST SP 800-53 Rev 5 | CA-8 — Security Assessments | Pentesting is a security assessment function whose value depends on timing and repeatability. |
| Recommendation — Increase assessment frequency for high-change environments and document current-state validation. | ||
Key terms
- Point-in-time pentest: A point-in-time pentest is a limited assessment performed on a schedule to identify weaknesses at a specific moment. It can be useful for verification, but it often becomes stale quickly because the system, exposure, and attacker opportunities change after the test window closes.
- Exposure freshness: Exposure freshness is the amount of time a security finding remains representative of the live environment. When systems change frequently, freshness drops fast, which means the gap between testing and remediation becomes a direct risk factor.
- Continuous Pentesting: A security validation model that checks exploitability repeatedly as systems change, rather than at a single scheduled point. It is designed for environments where releases, integrations, and attack surfaces move quickly, so evidence remains aligned to the current application state instead of a past snapshot.
- Attack-speed mismatch: Attack-speed mismatch is the gap between how fast attackers can exploit weaknesses and how slowly an organisation validates exposure. It becomes most visible in dynamic cloud and DevOps environments where the attack surface changes faster than conventional testing cycles.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that helps security teams connect identity controls to operational risk. It is designed for practitioners who need to govern identities across changing environments and reduce exposure windows.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org