Security testing service models

In short, project-based testing works best for “finished” systems that are no longer actively developed or that operate in protected environments such as internal networks.

• What is being tested?
• What is its purpose and who are the users?
• What other systems is it connected to?
• What kind of data does it handle?
• Is it exposed to the internet?

Project-based testing

A project-based security test is a short engagement designed to find vulnerabilities in the target system, evaluate their business and technical impact, and provide recommendations for remediation. Findings are documented in a formal report, which is then reviewed with the client.

The typical duration of a project depends on scope and ranges from one week for small systems to over a month for larger projects. On average, two to three weeks is common.

When to choose project-based testing:

• Certifications and audits (for example PCI DSS or ISO 27001)
• Due diligence in mergers and acquisitions
• Annual reviews of business-critical systems with limited ongoing development
• Systems where changes are limited to the environment or third-party components
  

Weaknesses of project-based testing

1. Point-in-time testing – Testing provides only a snapshot. There is no verification of fixes later on. If remediation is delayed, the client cannot be sure that vulnerabilities were corrected without commissioning another test.
2. Not suited for agile development – Applications developed with agile methods change constantly, sometimes daily. It is difficult to find a moment where a single test project would cover all significant risks. In practice, tests are often scheduled around major releases, but the application may change considerably soon after.
3. Budgeting and procurement overhead – If a system is tested annually and each round is re-tendered, the process can be heavy and expensive. Procurement includes requesting proposals, presenting the system to new providers, and comparing offers, which adds administrative costs.
4. Lack of continuity – If different teams test the system each year, testers cannot build deeper knowledge of the target. Every project starts from zero, which means testing may not reveal issues beyond the surface level.

Continuous testing

Continuous testing is delivered in regular cycles, typically monthly or quarterly. This keeps security up to date as new features are added and threats evolve.

Each cycle covers:

• New or changed functionality
• Verification of previous fixes
• Areas not tested for a long time

The first cycle is usually broader and resembles a project-based test in scope.

When continuous testing works well?

A continuous testing service is especially suitable for rapidly evolving systems such as:

• Agile mobile and web applications (Agile, SAFe)
• Cloud-based systems under constant change
• Any system with frequent new feature releases and internet exposure

Continuous testing reduces security risks compared to annual testing because issues are identified and fixed more quickly. It also highlights systemic security problems when similar vulnerabilities are found repeatedly, helping to improve how security is addressed in the development process.

Another benefit is continuity. Since the same team tests the system regularly, they can focus on deeper and more complex cases instead of starting from scratch with every round.

Weaknesses of continuous testing

1. Can be less cost-efficient – If a system only undergoes minor changes, continuous testing may add little value compared to periodic project-based tests.
2. Requires client commitment – If identified vulnerabilities are not addressed, the benefits of testing are limited. Reports may repeat the same findings from one cycle to the next if the development team does not act on them.
3. Relies on strong security governance – Continuous testing works best in organizations that treat security as an ongoing process and are committed to improving their practices over the long term.

Answers to these questions help clarify the real need and role of testing.

Why not both?

Many organizations benefit from a hybrid model. Systems have different life cycles and security needs, and combining both approaches can be the most effective choice. For example:

• Project-based testing before launch, followed by continuous testing during development
• Annual audits done as projects, combined with continuous testing of critical components
• Continuous testing for fast-moving systems, one-off projects for systems in maintenance mode

Summary

The right service model depends on the system life cycle, development approach, and business needs. Both project-based and continuous testing have strengths and limitations. Understanding these helps you make an informed decision.

Choose project-based testing if:

• The need is one-off (certification, audit, or due diligence)
• The system is in maintenance and not actively developed
• You want to minimize upfront costs
• Testing is aligned with major releases or big changes

Limitations:

• Point-in-time testing does not provide an up-to-date view of security.
• Verifying fixes for vulnerabilities requires a separate project.
• Each testing cycle may start from zero if the provider changes annually.
  

Choose continuous testing if:

• The application is actively developed (for example agile or DevOps-driven)
• You want to track security risks and changes closely
• Ongoing visibility into application security is important
• You want a dedicated team that builds deep system knowledge over time

Limitations:

• Requires organizational commitment and readiness to act on findings.
• May not be cost-effective if the system undergoes only minor changes.
• Without clear remediation processes, the benefits of testing may not be fully realized.

Final decision: what is right for you?

The choice depends on the following questions:

1. How often is the system developed?
   If development is continuous, choose continuous testing.
   
2. How important is it to verify vulnerability fixes?
   If it is critical, continuous testing is the best option.
   
3. Is the need one-off or part of a long-term strategy?
   For one-off cases, the project model may be sufficient.
   
4. What budget is allocated for testing?
   The project model is usually cheaper upfront but may include hidden costs.
   Over the long term, continuous testing often provides better value.
   

Explore our security testing services

• Penetration testing
  
  
• Continuous pen-testing