Forty questions buyers ask before signing a scoping call.

Penetration testing is an authorized, scope-bound simulation of how an attacker would compromise an application, API, network, or cloud environment. A senior tester combines manual analysis with targeted automated tooling to identify vulnerabilities, exploit them within agreed rules of engagement, and document findings with reproduction steps and remediation guidance.

A vulnerability scan is automated, runs against known signatures, and finds known issues. A penetration test is manual, runs against your specific application logic, and finds the issues a scanner misses — authentication bypass, broken authorization, business-logic flaws, chained exploit sequences. Auditors typically treat scans as supplementary evidence under SOC 2 CC7.1 and penetration test results as primary evidence.

A security audit is a paper review of policies, procedures, and controls against a standard. A penetration test is an active test of whether the technical controls actually hold up under attack. SOC 2 and ISO 27001 examinations include both: an audit of the program and pentest evidence of the technical control effectiveness.

A pentest is scope-driven and findings-driven — you list what should be tested and the deliverable is a report of vulnerabilities. A red team operation is objective-driven and detection-driven — you set an attacker goal (exfiltrate this data, reach this asset) and the deliverable measures how far the attacker got and whether the blue team noticed. Red team engagements typically follow MITRE ATT&CK.

In 2026 the most common drivers are: a SOC 2 Type II audit window, an enterprise customer security questionnaire, a regulatory mandate (PCI DSS Requirement 11.4, HIPAA Security Rule §164.308(a)(8), GLBA Safeguards Rule), or a significant change to in-scope systems. Series A SaaS companies typically run their first pentest 4 to 6 months ahead of their first SOC 2 Type II.

The AICPA Trust Services Criteria do not mandate penetration testing in a single dedicated line item. However, auditors treat a current third-party penetration test as the expected evidence under Common Criteria CC4.1 (ongoing evaluations) and CC7.1 (vulnerability identification). In our experience, every SOC 2 Type II audit we have supported has expected one.

The HIPAA Security Rule requires a periodic technical evaluation under §164.308(a)(8). It does not name "penetration testing" specifically. In practice, auditors and BAA counterparties expect pentest evidence of the technical safeguards under §164.312, particularly access controls, audit controls, and transmission security.

Yes — PCI DSS v4.0.1 Requirement 11.4 mandates external penetration testing (11.4.3), internal penetration testing (11.4.2), and segmentation testing (11.4.5) at least annually. Service providers must test segmentation at least every six months under 11.4.6. The methodology must be documented under 11.4.1.

ISO 27001:2022 does not name penetration testing as a specific control. However, Annex A 8.8 (Management of technical vulnerabilities), 8.29 (Security testing in development and acceptance), and 8.34 (Protection of information systems during audit testing) are typically satisfied via penetration testing in the surveillance audit cycle.

The FTC Safeguards Rule at 16 CFR §314.4(d)(2) requires annual penetration testing for non-banking financial institutions covered by the rule. The Rule also requires continuous monitoring or vulnerability scanning as a separate control.

Type I assesses whether controls are designed correctly at a point in time. Type II assesses whether controls operated effectively over an examination period (typically 6 to 12 months). Pentest evidence supports both. Most first audits start with Type I and graduate to Type II in year two, though some enterprise customers will demand Type II first.

The Trust Services Criteria are the framework underlying SOC 2 audits, published by the AICPA. They comprise the Security category (mandatory) plus four optional categories: Availability, Confidentiality, Processing Integrity, and Privacy. The Security category is built from Common Criteria (CC1-CC9). Pentest evidence most directly applies to CC4 (Monitoring), CC6 (Logical access), and CC7 (System operations).

These are the five Common Criteria points where pentest evidence is most commonly cited. CC4.1 covers ongoing evaluations of internal controls. CC4.2 covers communication of deficiencies. CC6.1 covers logical access controls. CC6.6 covers protection against external threats. CC7.1 covers vulnerability identification. See our SOC 2 penetration testing page for full mapping.

Requirement 11.4 in PCI DSS v4.0.1 mandates external penetration testing of the cardholder data environment perimeter, internal penetration testing of CDE systems, and validation that segmentation controls actually isolate the CDE. Exploitable vulnerabilities found during testing must be corrected and the affected scope retested per 11.4.4.

NIST SP 800-53 Rev. 5 control CA-8 covers Penetration Testing as part of Assessment, Authorization, and Monitoring. FedRAMP authorizations at Moderate and High baselines require annual independent penetration testing per the FedRAMP Penetration Test Guidance.

For a typical Series A SaaS scope (web app + API + cloud configuration), three to five weeks end-to-end: 3 to 5 business days of scoping, 10 to 20 business days of active testing, 5 to 7 business days of drafting and senior review, plus the retest window scheduled around your remediation timeline.

It depends on scope. For a single web application (Pattern 01), Series A engagements typically land in the upper four-figure to low five-figure range. For web plus API plus cloud (Pattern 02), it is a step up from there. We do not publish a rate card because scope is genuinely variable. A quick scoping call gets you a fixed price. See our pricing page.

Six artifacts in a single document: executive summary (1 page, non-technical), scope statement matching your SOC 2 boundary, methodology reference (OWASP / PTES / NIST 800-115), detailed findings with description / evidence / business impact / reproduction steps / remediation, severity ranking using CVSS v3.1, and a control-mapping appendix tying each finding to the relevant compliance control. Plus an attestation letter on CyberGuards letterhead.

A signed letter on the testing firm’s letterhead summarizing the engagement scope, dates, and high-level results. It is used as evidence in SOC 2 audit packages, customer security questionnaires, and Vanta / Drata / Secureframe trust centers. Distinct from the full report — the letter is shareable; the full report is typically NDA-gated.

Annual is the de facto industry standard. PCI DSS service providers must test segmentation every six months under 11.4.6. AICPA CC7.1 expects testing after significant changes to in-scope systems regardless of cadence. Most Series A SaaS customers we work with run one engagement per year plus a change-driven engagement when a major release lands inside the audit window.

At CyberGuards, one round of remediation verification is included in every engagement at no additional cost. Retest results are appended to the original report so your auditor sees the finding and its closure together. If a finding is not fully remediated by retest time, we mark it Open or Partially Remediated with notes rather than failing it silently. Additional retest rounds, if you need them, are quoted separately.

Production is preferred because that is what an attacker sees. Where production testing risks customer impact, we agree time-windows and read-only testing rules with you up front. Staging-only testing introduces evidence gaps that auditors increasingly question.

Black-box: testers receive no internal information; everything is discovered externally. Grey-box: testers receive scope information, test user credentials, and basic architecture. White-box: testers receive source code, system architecture diagrams, and full documentation. Most SOC 2 pentests are grey-box because that is the most realistic external-attacker scenario.

Penetration testing performed while logged in as a real application user. Tests authorization, privilege escalation paths, and tenant-isolation controls that an unauthenticated tester cannot reach. Most SOC 2 CC6.1 evidence comes from authenticated testing across user roles.

Yes. The report is yours to share with auditors, prospects, customers, and partners under the same NDA terms you use for your SOC 2 report. Most teams share a redacted executive summary in early sales conversations and the full report under mutual NDA during procurement diligence.

The OWASP Top 10 is the most widely cited list of web-application security risks, refreshed every 3 to 4 years by OWASP. Every web pentest at minimum covers the current Top 10. The 2021 version is the current canonical reference at time of writing.

A separate Top 10 for API-specific risks. The 2023 edition reorganized categories around authorization-centric risks: API1 BOLA (Broken Object-Level Authorization), API2 Broken Authentication, API3 Broken Object Property Level Authorization, API4 Unrestricted Resource Consumption, API5 BFLA (Broken Function-Level Authorization), and so on through API10.

The Penetration Testing Execution Standard. A seven-phase methodology covering pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting. A common methodology reference auditors look for in pentest reports.

A National Institute of Standards and Technology technical guide on security testing and assessment. It defines four phases of penetration testing (planning, discovery, attack, reporting) and is often cited as the methodology baseline for federal and federally-adjacent engagements.

A globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The framework organizes 14 tactics (Initial Access, Execution, Persistence, etc.) with hundreds of techniques mapped to each. Red team engagements are typically aligned to ATT&CK; penetration tests reference it for context.

The Common Vulnerability Scoring System. A 10-point severity score used to rank vulnerabilities by exploitability and impact. CVSS v3.1 is the current canonical version. Base scores can be adjusted using environmental and temporal metrics to reflect the actual risk in a specific deployment.

Common Weakness Enumeration. A taxonomy of software-weakness categories maintained by MITRE. Where a CVE identifies a specific instance of a vulnerability, a CWE identifies the underlying class of bug — useful for mapping multiple findings to a single root cause.

Common Vulnerabilities and Exposures. A standardized identifier for a publicly disclosed software vulnerability, issued by MITRE. Pentest reports cite CVEs to identify known issues in third-party software dependencies.

The OWASP Application Security Verification Standard. A controls catalog that defines verification requirements for web applications across three rigor levels. Used as the methodology baseline for most web-application pentests.

Penetration testing scoped to the API surface — REST, GraphQL, gRPC — separately from the web UI. Covers authentication on every endpoint, object-level and function-level authorization (BOLA, BFLA), mass-assignment, rate limiting, GraphQL introspection, query depth, resolver authorization. Aligned to the OWASP API Top 10 v2023.

Penetration testing of the customer-facing application, both unauthenticated and authenticated. Covers authentication flows, session management, MFA enforcement, authorization across roles and tenants, input validation, business-logic flaws, and OWASP Top 10 / ASVS coverage.

External and internal testing of network infrastructure plus configuration review of AWS, GCP, or Azure accounts. Covers IAM trust paths, network segmentation, encryption at rest and in transit, storage exposure, metadata service hardening, and cloud-specific attack paths like role assumption and cross-account access.

External testing is performed from outside the customer’s network boundary — what an internet-based attacker can reach. Required under PCI DSS 11.4.3 and expected under SOC 2 CC6.6. Internal testing is performed from inside the network — what an attacker with an initial foothold can reach. Required under PCI DSS 11.4.2.

A specific class of internal testing that validates whether network or cloud segmentation actually isolates in-scope systems from out-of-scope environments. Required annually under PCI DSS 11.4.5, every six months for service providers under 11.4.6. Also relevant for SOC 2 multi-tenant boundary validation.

Testing whether employees can be tricked into revealing credentials or granting access. Includes phishing simulations, pretexting calls, and physical-access attempts. Typically a separate engagement; included in standard pentest scope only when the auditor specifically requires it.

Broken Object-Level Authorization. An API vulnerability where the server returns or modifies data for an object the requesting user is not authorized to access, typically by trusting an ID supplied in the request. Listed as API1 in the OWASP API Security Top 10 v2023 — the most-common authorization category in our authenticated tests.

Insecure Direct Object Reference. The web-application term for the same class of issue as BOLA on APIs — a user can access another user’s data by manipulating an object identifier in the request. Maps to OWASP A01:2021 Broken Access Control.

Five things: document the system boundary; provision read-only or scoped IAM access for the testing team; create test user accounts across every role; agree the test windows and rate-limit posture; identify named contacts for scope and remediation decisions. Our SOC 2 readiness checklist covers 24 specific items.

A properly-scoped pentest does not run destructive payloads against production. Where a test requires write actions, we agree the scope, timing, and rollback plan in writing before the test runs. Critical findings that risk service availability are flagged immediately rather than held for the final report.

A signed engagement letter, scope documentation, test user credentials (for authenticated testing), read-only cloud IAM access (for cloud scope), API documentation if available, named escalation contacts, and confirmation of rate-limit / WAF rules that should not block legitimate testing.

Two roles: a primary scope contact (typically the CTO or security lead) who can answer scope and access questions, and an escalation contact for critical findings flagged mid-engagement. Both should be reachable during the test window.

We notify your escalation contact immediately rather than holding the finding for the final report. Most critical findings warrant remediation before the test completes; the report then reflects the post-fix state with the original finding and its closure documented together.

Any addition or change to the agreed test surface mid-engagement. We handle these by written addendum, never verbally. If you find an additional surface you want tested, we tell you the incremental days and cost in writing before any new work starts. You decide whether to proceed.