Security testing programme – 25 years of experience in a nutshell

When is a single test not enough?

A security testing programme is a strategic choice for organisations that: 

• Scale their operations – companies that build, maintain or run anywhere from a dozen to hundreds of applications and tests per year.
• Operate under strict compliance – organisations that must meet rigorous regulatory requirements (such as KNF, NIS2, DORA, TLPT or ISO 27001). 
• Secure their supply chain – businesses that are responsible for verifying the security of systems provided by third-party vendors and partners.
• Support for their own teams – companies with internal security departments that need external expert support and access to professional tools without the cost of building a complete in-house infrastructure.

For the SaaS sector (Software as a Service) – if you are building a single platform, we recommend an annual full-scale testing model. This supports compliance with your ISO 27001 Information Security Management System. To stay secure between annual audits, we supplement this with regular change-based testing after every major release of new features.

Connect with the author on LinkedIn!

How to order tests without excessive bureaucracy?

One of the main bottlenecks we have encountered throughout 25 years of testing experience is administrative red tape. Often, the procurement models used by our clients do not keep up with the fast pace of the projects they need to secure. 

Managing resources – how to tackle it?

In the security assessment process, data is the foundation. Without it, even the most experienced testing team cannot deliver reliable results. Penetration testing is not just about “clicking around an app”. It is a process that requires the right fuel – technical documentation and access credentials. When managing a portfolio of multiple applications, a streamlined process for gathering this data becomes a critical success factor for the entire programme.

The essentials – a complete set of input data

To start testing without delays, the security team needs a full set of resources, including:

• Access credentials – logins, passwords and multi-factor authentication (MFA) for various user roles (e.g., admin, standard user, manager). These are necessary to verify authentication mechanisms and the separation of privileges.
• Network access – whitelisting on firewalls or access to the tested systems via VPN connections.
• Structured test data – databases pre-loaded with records that allow us to test real business processes (e.g., active test payment cards or a history of user transactions within the app).

The onboarding survey – standardising the process 

The most effective solution we have developed over the years is a structured onboarding survey. It ensures:

• Standardisation – every application is described using the same key criteria.
• Time savings – your employees provide the data at their convenience, avoiding long, unnecessary meetings.
• Completeness – our Project Manager (PM) verifies that all information is complete and correct before the testing begins.

When a survey isn’t enough

For highly complex projects where a survey is insufficient, our Project Manager schedules a technical Kick-off meeting at least one week before the start date. The goal is to align the plan with reality and eliminate technical risks before they generate unnecessary costs.

Managing the unexpected – emergency procedures and “Backlog Management”

In the fast-paced IT environments of our clients, things rarely go perfectly. Test environments can go down the day before a scheduled test or critical deployment bugs might make the application unstable. In a traditional model, this means wasting paid man-days for a team of experts who are ready to work but have nothing to test.

To eliminate this risk, we use an emergency change procedure:

• The “starting blocks” principle – we recommend that our clients maintain a test backlog. This is a list of lower-priority applications that still require testing and are ready to be picked up at any time.
• Immediate application switch – if application “A” is not ready, the testing team immediately switches to application “B” from the backlog. This ensures that our specialists’ billable time is 100% utilised and that the overall programme schedule remains on track. 
• Cost optimisation – this approach changes the perception of testing. Instead of being seen as “projects with a high risk of delays”, testing becomes a seamless security production line.

With this process in place, the preparation phase ceases to be a bottleneck and becomes an efficient engine. It allows testers to focus on what they do best – finding security gaps – rather than waiting for access to the application or system being assessed. 

Execution – standards and “Low-Touch” delivery

The foundation of every professional assessment is its methodology. Our programme is built on globally recognised standards, such as OWASP Top 10, OWASP ASVS (Application Security Verification Standard), and OSSTMM (Open Source Security Testing Methodology Manual). We tailor these frameworks, along with our own proprietary checklists, to fit your specific business processes. 

However, theory is only half the battle. The key to success in large organisations is a “Low-Touch” delivery model – a partnership designed to provide maximum value while requiring minimal involvement from your staff during the testing phase.

Methodology that supports agility

By combining the OWASP ASVS framework with our internal guidelines, we can define the exact scope of every test. This gives you the confidence that every application feature has been verified against specific security requirements. As a result, the process is repeatable and the results are comparable across all your systems.

Critical vulnerabilities – the “fast track”

In a traditional testing model, clients often learn about bugs only after the work is completed. With our approach, time is on your side:

• Zero delays – if our team identifies a gap with a “critical” impact according to the CVSS (Common Vulnerability Scoring System) – such as data theft or remote code execution – we do not wait for the final report. We will notify you immediately.
• Instant notification – alerts about critical threats are sent directly to your security team through your preferred channel (e.g., a dedicated Slack/Teams channel, a Jira ticket or a direct phone call).
• Mitigation support – along with the vulnerability details, we provide initial remediation advice. This allows your team to start fixing the issue immediately while we continue testing other areas.

Connect with the author on LinkedIn!

Results – from PDF reports to automation

In a traditional approach, a penetration test report is a thick PDF document that often ends up in a drawer, only to be pulled out during a compliance audit. In a professional testing programme, we move away from this concept. The outcome of our work is not just a list of bugs, but active support for your remediation process. This includes regular meetings with your software developers or providing vCISO (virtual CISO) services to raise your overall security maturity. We focus on multi-level reporting tailored to the different stakeholders in your organisation. 

Integration with Vulnerability Management Systems – direct support for the security team and developers

For security to be effective, it must be “close to the code”. Instead of asking your developers to read through a long report, we can push our findings directly into the tools they use every day:

• The Jira ecosystem – every identified vulnerability can be sent to your Jira as a separate ticket. It includes a priority level, a technical description and most importantly, a clear, step-by-step guide to fixing the issue.
• Vulnerability Management (VM) Platforms – we support integration with tools such as ServiceNow, DefectDojo, Archer and Kenna Security. This allows you to manage vulnerabilities from multiple sources in one centralised location.
• Automated status tracking – when your team marks a bug as “fixed,” we are notified automatically. This allows us to schedule a retest instantly to verify the fix.

Proof of Coverage – what exactly did we test?

A common problem with many reports is that they only focus on what is “broken”. We go a step further by providing a full overview of the work performed.

• Clear boundaries – we precisely document which application modules, API methods and specific user roles were tested.
• Risk justification – if certain elements were left out of scope (e.g., at the client’s request or due to environmental stability), we clearly mark them as exclusions. This helps you identify residual risk areas.
• Transparency – our reports show more than just vulnerabilities and security flaws; they provide a complete view of all the testing activities completed during the assessment. 

Project closure and next steps

The final stage of the testing programme is where your organisation shifts from reactive “patching” to proactive learning. In a professional approach, the Lessons Learned meeting is more than just a review of identified bugs – it is a strategic workshop designed to eliminate the root causes of your security issues.  

Root Cause analysis – why does this bug keep coming back?

Instead of focusing on isolated incidents, we analyse trends across your entire application portfolio. We ask the tough questions that help your organisation grow: 

• Systemic analysis – does a specific type of vulnerability (e.g., Cross-Site Scripting) appear repeatedly because of outdated libraries or is there a lack of secure coding standards within the company?
• Skill gaps – do your developers know how to avoid these specific threats? If the same errors keep resurfacing, it is a clear signal that standard procedures need to be reinforced with dedicated Secure Development training (often referred to as Security Awareness for Developers).

Feedback loop

A testing programme is a living organism. Your feedback is crucial to ensuring that our activities evolve alongside your changing infrastructure: 

• Process optimisation – if the access provisioning phase took too long, we work together to refine the procedure for future tests, ensuring greater efficiency next time. 
• Tool fine-tuning – your feedback allows us to precisely configure our technical tools – such as scanners, manual scripts and checklists – and update our shared processes to focus on the threats that actually impact your business.
• Threat model updates – based on the results, we update the threat model for your industry. What was considered secure a year ago may require a completely new testing methodology today.

Moving from a craftsmanship model to a security production line

Modern testing programmes represent a shift from a craftsmanship model (isolated, one-off tasks) to a security production line that is: 

• Predictable – thanks to clear purchasing models, such as subscriptions or service catalogues. 
• Resilient to downtime – achieved through proactive backlog management and emergency procedures.
• Integrated – vulnerability data is fully embedded into your software development ecosystem, flowing directly into tools like Jira or ServiceNow.

Key take-aways for organisations commissioning security tests

Do not let bureaucracy block the publication of subsequent versions of your applications.

• If you run dynamic projects, avoid single orders. Choose a framework agreement or a subscription to start tests in a few days, rather than weeks.
• For repeatable systems (e.g., mobile applications of a similar scale), use a service catalogue – it will significantly simplify your budgeting.

The most expensive tester is the one waiting for a system password.

• Introduce a standard onboarding survey. Every Product Owner should be able to complete it before requesting a test.
• Provide testing environments with data reflecting real-world processes. Tests on an “empty” application rarely reveal business logic flaws. Furthermore, you waste the testing team’s time acquiring this data when they could be verifying your application’s security.

Avoid downtime.

• Always have one or two smaller applications ready “in the queue”. In the event of a main project environment failure, testers will immediately shift to these applications, optimising your budget.

A report at the end of the project is too late to inform about critical bugs.

• Establish an instant notification channel with your provider (Slack, Teams, or a direct phone call). Developers should be notified of a critical vulnerability immediately upon discovery, without waiting for the final report.

A PDF report is for the Board or Compliance Department, while a system bug is for the security department and the developer.

• Require us to export to Jira or another VM system (e.g., DefectDojo).
• Ensure Proof of Coverage. You need to know not only what is “leaky” but also what has been deemed secure (this is crucial for your residual risk assessment).

If the same bug appears repeatedly across different projects, the problem is not the code itself but a lack of knowledge among those creating it.

• Use Lessons Learned meetings to identify skill gaps within your team.
• Instead of conducting further vulnerability tests for the same class of errors, consider Security Awareness training for developers, based on the actual findings from your reports.

Adam Zachara Managing Partner