A penetration test is a controlled simulation of a cyber attack against a defined target system, carried out by ethical security specialists. In the Swiss market the question is rarely "whether," almost always "which knowledge level, which standard, how often." The three classic flavours, black-box, grey-box and white-box, have different strengths, costs and insight value. The choice directly determines the quality of findings and thus the value of the investment in a phase where cybersecurity budgets are under pressure anyway.

This article covers:

• The three knowledge levels black, grey, white, definition, typical use cases, cost.
• Methodological standards: OSSTMM 3, PTES, OWASP WSTG, NIST SP 800-115.
• Scoping best practices and typical Swiss market pricing (2025).
• Retest cadences, severity rating, reporting expectations.
• Legal aspects in Switzerland (data protection, professional secrecy, compliance evidence).

Legal and normative anchors are ISO/IEC 27001:2022 Annex A.8.29 (security testing in development and acceptance), A.8.8 (vulnerability management), Art. 8 DSG (data security), FINMA Circular 23/01 paras 59-65 (testing within operational risk), DORA Art. 24-27, OSSTMM 3 (ISECOM, 2010 with updates), PTES (Penetration Testing Execution Standard) and OWASP Web Security Testing Guide v4.2 (2024).

The three classic variants differ above all in the prior knowledge the test team has about the target:

• Black-box: The test team receives only the scope (e.g. a URL or IP range) and works without any internal information. Simulates an external attacker without insider knowledge. Advantages: high realism, tests the external attack surface. Disadvantages: large reconnaissance overhead, potential blind spots in deeper logic layers.
• Grey-box: The test team receives selected information, for example user accounts in various roles, architecture diagrams, a selection of API specifications. Simulates an insider or an external attacker after successful initial compromise. The best balance between realism and depth; the most common mode in Swiss practice.
• White-box: The test team receives full access including source code, architecture documentation, configuration snapshots, and database schemas. Highest depth and best coverage, suitable for security-critical applications and compliance evidence (e.g. SOC 2, ISO 27001 for SaaS vendors). Requires higher maturity at the client and stronger trust.

Selection guide: first-time pen-testers typically start grey-box. For external internet exposure (web, API, mail gateway) black-box is often useful as a reality check. For one's own software development and compliance evidence, white-box is the gold standard.

Reputable pen-test providers follow recognised methodologies, and the choice is fixed in the scoping document:

• OSSTMM 3 (Open Source Security Testing Methodology Manual): Structured seven-phase framework with its own risk assessment model (RAVs – Risk Assessment Values). Strong in infrastructure testing, less so in web applications.
• PTES (Penetration Testing Execution Standard): Seven phases (pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, reporting). Pragmatic and most widely used in DACH.
• OWASP Web Security Testing Guide v4.2: The gold standard for web application testing. Contains around 100 detailed test cases organised in 11 categories (information gathering, configuration, identity management, authentication, authorisation, session management, input validation, error handling, cryptography, business logic, client-side).
• OWASP ASVS v4 / v5: Application Security Verification Standard with three maturity levels (L1 minimal, L2 standard, L3 highly critical). Structured checklist approach, complementary to WSTG.
• NIST SP 800-115: US government guideline, rather generic, little used in EU/CH but occasionally required by US customers.
• MITRE ATT&CK: Not a test standard, but the de facto vocabulary for adversary TTPs. Should be used for severity rating and reporting.

In Swiss practice we typically combine PTES as the process framework with OWASP WSTG for web components and MITRE ATT&CK for reporting.

A well-scoped pentest delivers usable results at a calculable price. Key ingredients of robust scoping:

• Asset list: precise enumeration of target IPs, URLs, API endpoints, mobile apps; clarify cloud hosting (which regions, which provider).
• Knowledge level: black, grey, white, explicitly documented with the concrete information handed to the test team.
• Test window: weekdays, time of day, emergency escalation, contacts; for productive tests, an explicit availability risk trade-off.
• Objectives: "What is success?", e.g. authentication bypass, data exfiltration, privilege escalation, lateral movement.
• Out-of-scope: what must not be tested? (Production DB manipulation, DoS, social engineering without explicit release).
• Rules of engagement: which techniques are allowed? What happens on discovery of a critical vulnerability (immediate escalation or test to the end)?
• Engagement letter: client authorisation, NDA, liability allocation, evidence of provider insurance.

Swiss market pricing (2025, indication): small web app (10-15 endpoints, grey-box) typically CHF 12,000-25,000; mid-sized SaaS platform CHF 35,000-80,000; external infrastructure audit with 50-200 IPs CHF 20,000-50,000; internal network test with Active Directory CHF 30,000-70,000.

A one-off pentest is a snapshot. Most standards (ISO 27001 Annex A.8.29, FINMA Circular 23/01 paras 59-65, DORA Art. 25) require regular repetition. Common cadences:

• Annually: external web applications, mobile apps, cloud infrastructure, and after every major release.
• Half-yearly or at every major release: critical SaaS platforms, regulated financial apps, healthcare systems with patient data.
• Every 2-3 years: internal network architecture, OT/ICS environments (with special precautions).
• After every material change: code reviews, architecture changes, new integrations, cloud migrations.

Retests after remediation are essential. Typical flow: pentest → report with prioritised findings (typically CVSS 3.1 plus organisation-specific risk factor) → remediation by the development team → retest of the specific findings (typically 4-8 weeks after the initial test, at around 20-30% of the initial effort). Severity rating typically follows CVSS 3.1 (four tiers: low, medium, high, critical) or OWASP Risk Rating; what matters is organisation-specific contextualisation, a CVSS "high" on an internal test system reads differently from one on a publicly accessible productive API.

The report is the main deliverable. A professional pentest report has a consistent structure:

• Executive summary (2-4 pages): context, methodology, key findings, risk picture, strategic recommendations. Readable for the management body without a tech background.
• Scope & methodology: what was tested, which standard, which knowledge level, which test window.
• Findings overview: tabular by severity, with short description, CVSS score, affected assets and recommendation.
• Detail findings: per finding: description, technical evidence (screenshots, request/response samples, proof-of-concept code where appropriate), impact, recommendation, references (CWE, OWASP, MITRE ATT&CK ID).
• Appendix: tool list, out-of-scope statement, test diary, custom tools of the test team where relevant.

Quality markers of a good report: traceable reproduction steps rather than tool output alone (Nessus/Burp dumps do not constitute a pentest report), clear prioritisation with context, actionable recommendations rather than textbook phrasing, and, crucial, an honest assessment of what was NOT tested and which residual risks in scope remain unaddressed. A report without a "Limitations" section is a suspicious report.

Pentests in Switzerland touch several legal regimes that must be reflected in the contract:

• Criminal law: Art. 143 (unauthorised data procurement) and 143bis SCC (unauthorised intrusion into data processing systems) are the classic "hacker provisions." Pentests require written client authorisation in place before start; a blanket "we tolerate it" statement is insufficient. For cloud tests, the cloud provider's authorisation is also required (AWS, Azure, Google Cloud have self-service approval processes).
• Data protection: If personal data is processed during test activities (e.g. customer accounts in a web app), Art. 6 ff. DSG and Art. 9 (processor agreement) apply. Recommendation: test accounts without real personal data or explicit agreement on processing of personal data.
• Professional secrecy: For tests against banks (Art. 47 Banking Act), lawyers (Art. 321 SCC) and physicians (Art. 321 SCC), secrecy duties are particularly strict. Testers must sign NDAs and ideally hold Swiss citizenship or residence.
• Compliance evidence: Pentest reports serve as evidence vis-à-vis FINMA (Circular 23/01), ISO auditors (Annex A.8.29), SOC 2 examiners, DORA supervisors and EU customers. Retention period: typically 5-10 years.

More on our pentest offering at penetration testing.

SIDD delivers penetration tests for Swiss SMEs, mid-market and regulated entities across all three knowledge levels. We use PTES as the process framework, OWASP WSTG / ASVS for web components, OWASP MASVS for mobile apps and MITRE ATT&CK for reporting. Our testers are CREST, OSCP or OSCE3 certified and follow a documented QA process.

Typical entry packages: a web-application test in grey-box configuration with OWASP WSTG methodology (CHF 15,000-30,000 depending on complexity), an external infrastructure test against internet-exposed systems, an Active Directory security audit, or a full TLPT for regulated financial entities (see the TLPT article). For ongoing threat-landscape monitoring we combine pentests with regular vulnerability scanning.

Arrange a non-binding scoping conversation at /kontakt or request a fixed-price quote at /offerte. We typically deliver a written quote with detailed effort plan, methodology description and delivery times within five working days of the scoping call.