When new clients are preparing for a penetration test they typically ask a set of recurring questions. Here are the most common ones, grouped by category for clarity:

BEFORE

1. What kind of penetration test do I need?

There are different types of penetration tests: web application, API, kiosk, cloud, mobile, and more. I'd start with two key questions: First, are there any compliance requirements that mandate testing, like PCI-DSS? If not, the second question is: What are you particularly worried about, and what would you like us to focus on?

The answers to these questions will help determine whether you need a broad assessment or something more targeted, like a specific application security review.

2. What's the difference between black-box, gray-box, and white-box testing?

This refers to the level of knowledge testers have about your system before we begin:

• Black-box testing is performed without any prior knowledge of the application or system. We approach it exactly like an external attacker would.
• Gray-box testing involves partial knowledge of the system. You might share some architectural documentation, network diagrams, or portions of source code with the testing team.
• White-box testing provides full access to source code and internal system documentation, allowing for the most comprehensive examination of potential vulnerabilities.

3. How much does it cost?

Cost is typically tied to the level of effort required. The more complex and extensive the scope, the more time we'll need to invest. Keep in mind that pricing isn't just for hands-on-keyboard testing, it also covers project kickoffs, test environment setup, configuration, detailed report writing, final presentations, and any retesting of remediated vulnerabilities.

4. How long will the test take?‍

Timeframes vary significantly based on scope and complexity. A simple web application might take 1 week from start to final report, while a comprehensive assessment could take 4-6 weeks or more. We'll provide a detailed timeline during our initial scoping conversation.

5. What will you need access to?

At minimum, we typically need URLs or IP addresses, any necessary credentials for authenticated testing, and specific instructions for accessing staging environments or VPNs. The exact requirements depend on what we're testing and your preferred approach. If you want us to perform source code review alongside dynamic testing, we'll need access to your code repositories (GitHub, GitLab, etc.). We'll work with you to determine the most secure way to provide this access.

6. Will this cause downtime or affect users?‍

Concerns about disruption are unique to each environment and depend on whether we're testing in production or a dedicated testing environment. We usually recommend testing in a non-production environment when possible as this removes most concerns and allows for more thorough testing without business impact.

That said, proper penetration testing on modern infrastructure should be largely harmless. We do use techniques that mirror real-world attack scenarios, however, we use them in a manner that is harmless to your systems, in a way that your systems should be able to handle. However, in production environments, there are legitimate concerns about account lockouts or database impacts from injection testing if testers aren't careful to limit their impact.

7. Is this test compliant with (PCI-DSS, SOC 2, ISO 27001)?

‍It's crucial to know upfront if your test must meet specific regulatory or audit requirements. This ensures our testing scope and methodology align with what auditors expect. For example, PCI-DSS compliance requires testing the complete payment flow and examining how cardholder data is protected at rest, in storage, and in transit. Different standards have different focus areas, and we'll tailor our approach accordingly.

DURING

8. Can we monitor what you're doing?‍

Absolutely! If you have SIEM alerts, security dashboards, or other monitoring tools in place, please use them to track our activity. If it's been pre-agreed to leave defensive tools like WAFs enabled, we'll work with those constraints.

However, we do ask that you avoid actively interfering with the test, such as manually blocking our access or disabling accounts mid-test. Here's the reality: you're unlikely to get advance warning from actual attackers about when they'll be in your system. If you spend your testing budget fighting us instead of letting us find vulnerabilities, you're missing the point of the exercise.

If you want to test your team's response capabilities while we're working, consider a proper red team engagement instead. Just be aware that many vendors claim to offer "red teaming" when they're really just rebranding penetration tests. True red team exercises are stealthy (no advance warning to your blue team), full-scope (targeting people, processes, and technology), and cross-disciplinary (combining network, application, physical, and social engineering tactics).

9. What should we do if our defences trigger alerts?‍

This is entirely your choice. You can either instruct your security team to ignore alerts during the testing window, or use this as a training opportunity for them to practice their incident response procedures.

Just remember to be fair to your security teams, if you don't have a WAF or aren't capturing application-level traffic, there's a good chance they won't be able to detect our activities anyway. Set realistic expectations about what your current tooling can actually see.

10. What are you allowed or not allowed to do?‍

This should be clearly defined in our "rules of engagement" document before we begin any testing. Ideally, this document specifies exactly what we're authorized to test, if it's not explicitly included, we won't test it.

We'll also establish any time-based restrictions that might be important for your business. E-commerce sites might need testing paused during peak shopping hours, or you might have scheduled maintenance windows we need to avoid.

Common exclusions we see include:

• No social engineering attacks
• No denial of service testing
• No testing of third-party systems
• Specific time windows when testing must stop

AFTER

11. What kind of report do we get?‍

You'll receive a comprehensive report with multiple components tailored to different audiences. The executive summary provides high-level findings, business risk context, and strategic recommendations for leadership. The technical section includes detailed vulnerability descriptions, proof-of-concept exploits, and remediation guidance for your technical teams.

Each finding includes risk ratings along with clear explanations of potential business impact. We also prioritize findings based on exploitability and business risk to help you focus your remediation efforts where they'll have the most impact.

12. Will you help us fix the vulnerabilities?‍

Our remediation guidance comes in detailed written form within the report. This includes specific steps, code examples where applicable, and links to relevant security resources. However, your internal teams or a separate development contractor would need to perform the actual fixes.

We're available for clarification calls if your team has questions about our recommendations, but we don't perform hands-on remediation work as part of the standard penetration testing engagement.

13. Can we retest after fixing issues?‍

We typically price in retesting any of the vulnerabilities, within a time-period. For clarity, this includes retesting of the original vulnerability only. It does not include the discovery of new vulnerabilities.

Yes, we typically include retesting in our initial pricing, usually within a window after the penetration test has been completed. This retesting covers the original vulnerabilities we identified to confirm they've been properly addressed. Important note: retesting focuses on verifying that the specific issues we found have been resolved. It doesn't include hunting for new vulnerabilities that might have been introduced during the remediation process, that would require a separate engagement.

‍