When Does an Organization Need Continuous Penetration Testing?

Geplaatst op: 16 September 2026

An organisation needs continuous penetration testing as soon as the risks of an undiscovered vulnerability outweigh the costs of ongoing testing. In practice, this applies to most organisations that manage sensitive data, serve customers through digital systems, or fall under regulations such as NIS2. The questions below help you determine whether your organisation is ready for a continuous testing programme and what you can expect.

What distinguishes continuous penetration testing from an annual pentest?

Continuous penetration testing differs from an annual pentest in that testing is not a one-off snapshot, but an ongoing process. Where an annual pentest measures security as it exists at that moment, continuous pentesting provides insight into vulnerabilities that arise from changes in systems, configurations, vendors, or attack techniques throughout the entire year.

An annual pentest is essentially a photograph of a moving target. Cybercriminals develop new attack techniques 365 days a year. By the time a traditional pentest would notice those developments, an attacker has long since found a way in. Every system change, new application, or modified cloud configuration can open a new attack path that did not exist in the previous test.

Continuous pentesting works differently: it combines periodic manual tests with continuous monitoring of the attack surface. This way, not only known vulnerabilities are found, but also the combined attack paths that emerge when multiple small weaknesses are exploited together. Attackers do not see isolated findings; they see attack paths. A manual pentest is the technical backbone of this, but the real value lies in continuity.

Which organisations are at the greatest risk without continuous testing?

Organisations at the greatest risk without continuous penetration testing are Managed Service Providers, companies that fall under NIS2, organisations with complex cloud infrastructure, and parties with access to sensitive customer data. For MSPs, there is an additional dimension: compromising one MSP gives an attacker direct access to all of that MSP’s customers.

This makes MSPs a prime target for cybercriminals. The responsibility an MSP bears for its customers is greater than for other organisations, meaning the security of the MSP effectively also determines the security of its customers. A weak link in the chain is enough for an attacker to cause widespread damage.

Other organisations at elevated risk are companies that:

• Regularly integrate new software, systems, or vendors
• Work with cloud platforms such as Azure or AWS, where misconfigurations arise quickly
• Fall under legal obligations that require demonstrable security
• Depend on external identities, permissions, or supply chains
• Have previously experienced a security incident

For all these organisations, an annual test is insufficient to keep pace with how quickly the attack landscape changes.

How does an organisation know if it is ready for continuous pentesting?

An organisation is ready for continuous penetration testing when it understands that security is not an endpoint, but an ongoing process. The first question is not technical in nature, but mental: does the organisation view security as a living capability that requires constant attention, or as something you arrange once?

From a technical perspective, a basic level of IT management and documentation is a prerequisite. Without insight into its own environment, it is difficult to properly interpret and act on test results. Organisations that have never had a pentest conducted typically start with an initial assessment: a manual pentest that maps the actual vulnerabilities and simultaneously tests the security mindset.

As an organisation, you are ready for continuous pentesting when:

• Someone is responsible for information security (internally or via a virtual CISO)
• Findings are acted upon and not merely reported
• The organisation is willing to take uncomfortable outcomes seriously
• There is management support for structural investment in security

What are the signs that an organisation is waiting too long to test?

Signs that an organisation is waiting too long for continuous penetration testing include: a last pentest that took place more than twelve months ago, recent system changes that have not been tested, unfamiliarity with its own attack surface, and a security policy that exists mainly on paper but is not tested in practice.

Other warning signs are:

• Employees click on phishing links during internal tests or have never been tested on this
• New cloud services or SaaS applications have been adopted without a security review
• Vendors or MSPs have access to systems without that access ever having been checked
• The organisation relies solely on a vulnerability scanner for security testing
• There is no clear picture of which accounts hold which permissions

That last point is telling: an attacker does not only look at technical vulnerabilities, but also at organisational structures, identities, permissions, and combinations of weaknesses. A vulnerability scan finds known CVEs, but misses the combined attack paths that only become visible during manual, offensive testing. The longer an organisation waits, the greater the chance that an attacker has already found those paths.

What happens during a continuous penetration testing programme?

During a continuous penetration testing programme, an organisation’s security is continuously tested through a combination of manual pentests, attack simulations, and monitoring of the attack surface. It begins with a thorough initial assessment and then builds on the results of previous rounds.

A good programme works in layers:

1. Known vulnerabilities (Layer 1): Checking for known CVEs, public exploits, and whether patches have been correctly applied.
2. Individual weaknesses (Layer 2): Incorrect configurations in cloud platforms, overly broad permissions, identity weaknesses, and insecure application settings.
3. Combined attack paths (Layer 3): Investigating what happens when multiple small weaknesses are combined. An SSRF vulnerability combined with a managed identity, Azure RBAC permissions, and access to a Key Vault can together lead to full control over cloud resources, while each individual finding may seem relatively minor.

In addition to technical tests, a complete programme also includes red teaming, where a simulated attacker approaches the organisation as a real cybercriminal would: by first understanding how the organisation is structured, which vendors have access, and where the gaps exist between existing security measures. After each test round, the organisation receives concrete findings with priorities, so that follow-up action is immediately possible.

How does continuous pentesting relate to NIS2 obligations?

Continuous penetration testing directly aligns with NIS2 obligations, because the directive requires organisations to implement demonstrable and ongoing measures in the area of risk management and security. A one-off annual pentest is in most cases insufficient to comply with the spirit of NIS2, which calls for structural management of security risks.

NIS2 requires, among other things, that organisations take appropriate technical and organisational measures to manage the risks to network and information systems. Continuous pentesting provides the evidence for this: ongoing tests demonstrate that an organisation is actively identifying vulnerabilities, following up on them, and adapting its security based on current findings. That is precisely what regulators and auditors are looking for.

In concrete terms, continuous pentesting helps with NIS2 by:

• Demonstrating that security measures are being tested and adjusted
• Providing documentation of identified vulnerabilities and the follow-up actions taken
• Keeping the attack surface up to date, even after system changes
• Providing insight into the security of the supply chain and external access points

Organisations that fall under NIS2 and do not yet have a structural testing programme face not only an operational risk but also a compliance risk.

How Q-Cyber helps with continuous penetration testing

Q-Cyber offers organisations a structured programme for continuous testing, built on the conviction that you cannot defend what you do not test. Our offering includes:

• Manual pentests by certified ethical hackers who think like an attacker, including combined attack paths that automated scanners miss
• Continuous-Q®, our programme for MSPs and organisations that want to be tested structurally and continuously, including red teaming and attack simulations
• NIS2 advice and policy development, ensuring that test results also align with compliance obligations
• Virtual CISO services for organisations that do not have an internal security expert but still want to maintain control over their security
• Independent advice, without dependency on software vendors or other suppliers

Want to know whether your organisation is ready for continuous penetration testing and what the first step is? Get in touch via our contact form and we will look at your organisation’s situation together.

Lees meer

How Are New Attack Paths Discovered Throughout the Year?

Geplaatst op: 4 September 2026

Cyber threats never stand still. Attackers are constantly exploring new ways to breach systems, and the combination of changed permissions, new cloud resources, and unknown vulnerabilities means your attack surface looks a little different every day. Relying solely on an annual snapshot only tells you that you were tested on that one day — not that you were protected for the remaining 364.

In this guide, you’ll learn step by step how to discover, monitor, and address new attack paths throughout the year. You’ll work through a cyclical process that starts with mapping your attack surface and ends with an improvement loop that keeps your security continuously sharp.

Map your current attack surface

Before you can discover new attack paths, you need to know exactly what you’re defending. An attacker begins their reconnaissance the same way: mapping which systems, identities, vendors, and permissions exist. Do the same from a defender’s perspective. Without this overview, you’ll lack the context needed to interpret vulnerabilities discovered later.

1. Inventory all active systems, applications, and cloud resources, including recent additions that fall outside the regular change management process.
2. Document all accounts, service accounts, and external access points, along with their associated rights and roles.
3. Map out vendors and MSP connections that have access to your environment, because a pentest regularly shows that supply chain access is underestimated.
4. Note which security measures are already in place and where gaps between those measures exist, whether intentional or not.

After this step, you have an up-to-date baseline: a structured overview of your attack surface. Verify that it matches reality by comparing it against your CMDB or asset register. Discovering undocumented systems or forgotten accounts? Then you’ve already found your first potential attack paths.

Set up continuous monitoring for new vulnerabilities

With your attack surface mapped, the next step is setting up monitoring that automatically flags new vulnerabilities as they arise. An environment changes continuously: applications are updated, accounts are added, and cloud configurations are modified. Every change can open a new attack path. Monitoring ensures you keep track of those changes without waiting for the next scheduled test.

Choose the right monitoring layer

Use a combination of automated vulnerability scanning and configuration monitoring. Automated scans are excellent for checking known CVEs and basic hygiene, but they miss the context that a human analyst can see. Therefore, also set up alerts for configuration changes in your cloud environment, permission changes, and the creation of new privileged accounts.

Define thresholds and escalation paths

Determine which findings require immediate action and which should be included in the regular improvement process. A critical vulnerability in a system with direct internet access demands a different response speed than a low-risk misconfiguration in an isolated system.

1. Set up automatic notifications when new CVEs appear that apply to your software and versions.
2. Configure alerts for unexpected changes in access rights or new external connections.
3. Document who is responsible for follow-up and within what timeframe.

After setup, verify that the monitoring actually triggers by making a test change in a non-production environment. If nobody receives a notification, the escalation path isn’t working as intended.

Use threat intelligence to track attack techniques

Monitoring tells you what is changing within your own environment. Threat intelligence tells you what attackers are developing outside it. Cybercriminals work 365 days a year on new techniques, and those techniques often reach your sector sooner than you’d expect. By actively tracking which attack methods are emerging, you can proactively assess whether your environment is vulnerable to an attack path that hasn’t yet appeared in standard security playbooks.

1. Subscribe to relevant threat intelligence feeds aligned with your sector, technology stack, and region. Think of feeds from national CERTs, MITRE ATT&CK updates, and sector-specific ISACs.
2. Translate new attack techniques into concrete questions about your own environment: Does this technique exploit a weakness that could be present in our environment?
3. Link relevant techniques to the attack paths you mapped earlier and assess whether existing controls are sufficient.
4. Share relevant intelligence internally with the people responsible for systems or processes that could be affected.

After this step, you have a current picture of how attackers think and which combinations of vulnerabilities, misconfigurations, and identities they are currently exploiting. That insight is the input for the next step: validating whether those attack paths are actually walkable in your environment.

Validate discovered paths with simulated attacks

Theory and practice regularly diverge in cybersecurity. A vulnerability that looks serious on paper may be mitigated in your specific environment by other controls. Conversely, a combination of seemingly low-severity findings can together form a working attack path that nobody anticipated. Validation through simulated attacks gives you the only reliable confirmation: is this path genuinely walkable?

Automated vulnerability scans find known technical deviations, but they don’t reason like an attacker. A human ethical hacker looks at the combination of identities, permissions, cloud misconfigurations, and access rights to determine whether an attack path runs from point A to point B. That is precisely what red team ethical hacking adds to your validation process.

1. Prioritise the paths to be validated based on potential impact and the likelihood that an attacker would choose this path.
2. Run targeted tests on the specific combinations that emerged from your monitoring and threat intelligence, not just on individual vulnerabilities.
3. Document which paths are genuinely walkable, which controls blocked them, and where the chain broke.
4. Also record which paths were not walkable and why, so you understand which controls are effective.

After validation, you know which attack paths pose real danger and which are covered by existing controls. This is considerably more valuable than a list of individual findings, because it helps you prioritise based on actual attack risk rather than theoretical severity.

Incorporate findings into a cyclical improvement process

The previous steps produce insights, but insights without follow-up change nothing about your actual resilience. The final step is embedding all findings into a structured improvement cycle that converts results into concrete actions and links those actions to the next round of monitoring and validation.

1. Categorise findings by priority: which attack paths require immediate remediation, which can be included in the regular patch process, and which do you consciously accept as residual risk?
2. Assign ownership to each finding and set a concrete deadline for follow-up.
3. After remediation, verify that the attack path has actually been closed by running a targeted retest — don’t rely on the assumption that the fix works.
4. Use the findings as input for the next cycle: update your attack surface inventory, refine your monitoring rules, and update your threat intelligence priorities.
5. Report periodically to relevant stakeholders on progress — not in terms of the number of findings resolved, but in terms of attack paths closed and improved resilience.

Verify that the cycle actually closes: are findings from the previous round demonstrably incorporated into the current one? An improvement process that exists only on paper but does not lead to changed configurations, patching, or policy adjustments creates a false sense of security. Dynamic resilience only emerges when testing, learning, and improving continuously follow one another.

How Q-Cyber helps discover new attack paths

The process described above sounds manageable, but in practice it requires specific expertise, tooling, and capacity that not every organisation has in-house. We help organisations set up and maintain this process, without making you dependent on software vendors or other suppliers.

• Mapping your attack surface: our consultants perform a thorough initial analysis of your environment, including identities, permissions, cloud resources, and supply chain connections.
• Manual pentests as a baseline: certified ethical hackers test your environment the way a real attacker would, including advanced attack chains that automated tools miss.
• Continuous insight via Continuous-Q®: after the initial pentest, our specialists continuously monitor new attack paths and changes in your environment, so you have insight not just on the test day but throughout the entire year. You can read more about this programme on the Continuous-Q® page.
• Red team simulations: our red team ethical hacker acts as a simulated attacker and validates whether discovered paths are genuinely walkable.
• Pragmatic advice: we provide concrete recommendations and help you set up an improvement cycle that fits the scale and risk profile of your organisation.

Want to know which attack paths currently exist in your environment? Contact us for a no-obligation conversation.

Lees meer