Penetration Test Report Example

Document Details

Revision History

Table of Contents

1. Executive SummaryOverall risk, top priorities, statistics
2. Scope and MethodologyFrameworks, in-scope targets, risk rating
3. Findings SummaryAll 13 findings, CVSS scoring, status
4. Detailed Findings2 of 13 shown in this preview
5. Retest Resultsv1.0 to v2.0 remediation trail
6. Compliance Evidence PackageSOC 2 + ISO 27001 control mapping (Growth Plan)
7. AppendixGlossary, references, contact
8. DisclaimerScope limits, legal terms

Executive Summary

Cybersecify Consulting (OPC) Private Limited was engaged by Acme SaaS Pvt. Ltd. to conduct a grey-box penetration test of their primary SaaS platform and its supporting API infrastructure. The engagement covered two scopes: the web application at app.acmesaas.io (Scope 1) and the REST API at api.acmesaas.io/v2 (Scope 2).

The assessment was performed by a senior team led by Rathnakara GN (OSCP) and Ashok Kamat (CCIO), following the OWASP Web Security Testing Guide (WSTG) v4.2, OWASP Application Security Verification Standard (ASVS) 5.0.0, and the Penetration Testing Execution Standard (PTES). Findings are mapped to OWASP Top 10:2025, the current edition. Where a category changed from the 2021 edition, the report notes the prior label for teams still tracking against 2021. The testing approach combined manual exploitation with automated scanning, focusing on business logic flaws, privilege escalation, and chained attack scenarios that automated tools typically miss.

Active testing ran from 6 July 2026 to 17 July 2026 across 10 business days (5 business days per scope), with reporting prepared concurrently. The v1.0 initial report was delivered on 17 July 2026 at the close of the engagement, in line with the Growth Pentest Plan 10 business day commitment. This v2.0 final report supersedes v1.0 and reflects the post-retest state captured on 14 August 2026 (all 13 findings remediated and verified).

Key Statistics

Business Impact Summary

The most significant risk to Acme SaaS is the combination of an Insecure Direct Object Reference (IDOR) vulnerability in the billing API and a broken authentication flaw in the API token refresh mechanism. Together, these findings mean that any authenticated user on the platform can access billing records belonging to other organisations, and a compromised or expired token can be refreshed indefinitely without re-authentication. For a B2B SaaS platform handling financial transactions, these represent direct threats to customer trust, regulatory compliance, and revenue.

If exploited, the IDOR vulnerability alone could expose the billing records (names, addresses, invoice amounts, partial payment details) of every organisation on the platform. This would likely trigger mandatory breach notification obligations under India's Digital Personal Data Protection Act and, for any EU-based customers, under GDPR. The reputational cost to a SaaS company during a fundraise or enterprise sales cycle could be substantial.

Top 3 Priority Findings

Strategic Recommendation

We recommend Acme SaaS treat the two critical findings as P0 and remediate them before the next production release. The billing API IDOR points to a missing server-side, organisation-level authorization check on invoice access; the SQL injection points to unparameterised queries in the search endpoint. Both are pinpointed to the exact endpoint in Section 4. The specific code change depends on Acme SaaS's own stack and architecture, which the engineering team is best placed to judge. Once these are resolved, the remaining high and medium findings should be addressed within the next two sprint cycles. The compliance evidence package (Section 6) maps all findings to SOC 2 and ISO 27001 controls, directly useful for Acme SaaS's upcoming SOC 2 Type 2 audit preparation.

Scope and Methodology

Risk Rating Definitions

All findings in this report are scored using CVSS v3.1 and v4.0 (see Section 3 for dual-vector documentation). The severity bands below are identical across both versions. Remediation priority is set by Cybersecify in consultation with the client based on exploitability, business context, and remediation effort.

In-Scope Targets

Testing Approach

Grey-box testing was performed with authenticated access. The Acme SaaS engineering team provided two sets of credentials: a standard user account (Member role) and an administrator account (Admin role). This approach simulates both external attacker scenarios (credential compromise, account takeover) and insider threat scenarios (malicious or compromised employee).

Manual testing was the primary method. Automated scanning was used to supplement coverage and identify common misconfigurations, but all critical and high findings in this report were discovered through manual analysis and exploitation. Business logic testing, privilege escalation, and chained-attack scenarios were performed manually.

Active testing was performed against the staging environment, with read-only validation against production. Staging and production run the same application codebase and an equivalent security configuration (matching framework versions, authentication flows, and access-control rules), confirmed with the Acme SaaS engineering team at kickoff, so the findings represent the production system covered by the audit.

Methodology and Standards

Every finding in this report names the test case it came from, in the findings summary tables in Section 3 and in the finding entry itself. That is how a reader checks the work against the methodology instead of taking the list above on trust. Scope 1 findings cite an OWASP WSTG v4.2 identifier, for example WSTG-ATHZ-04 for the insecure direct object reference in Section 4. Scope 2 findings cite an OWASP API Security Top 10 2023 item instead, because WSTG v4.2 contains exactly one API test case (WSTG-APIT-01, Testing GraphQL) and Scope 2 is a REST API. Citing a web test case against a REST endpoint would look thorough and mean nothing.

Tools Used

Out of Scope

Denial-of-service testing, social engineering, physical security assessments, and testing against third-party SaaS integrations (Stripe, AWS Cognito) were excluded from this engagement. All testing followed responsible disclosure practices.

Findings Summary

Each finding is scored under both CVSS v3.1 (for parity with NVD, CISA KEV, and most vendor advisories) and CVSS v4.0 (current FIRST standard since November 2023). Severity bands are identical across both versions. Detailed finding entries include full v3.1 and v4.0 vectors. Scores reflect what the original engagement recorded; vectors are documented for reproducibility against the FIRST CVSS calculator.

Severity Distribution

Scope 1 Findings: Web Application (app.acmesaas.io)

Status column reflects v2.0 final state after retest verification. Original v1.0 status for all findings was Open. See Section 5 for full retest history.

Scope 2 Findings: REST API (api.acmesaas.io/v2)

Status column reflects v2.0 final state after retest verification. Original v1.0 status for all findings was Open. See Section 5 for full retest history.

Detailed Findings

Two of 13 findings are shown in full below. The remaining 11 findings follow the same format in the complete report.

GET /api/v2/billing/invoices/INV-2026-00098 HTTP/1.1
Host: api.acmesaas.io
Authorization: Bearer eyJ0eXAi...[REDACTED]
X-Org-Id: org_acme_test_001
Accept: application/json

{
  "invoice_id": "INV-2026-00098",
  "org_id": "org_different_company",
  "org_name": "[REDACTED]",
  "billing_email": "[REDACTED]@company.com",
  "amount": 24999.00,
  "currency": "INR",
  "plan": "Growth Annual",
  "payment_method": "**** **** **** 4832",
  "billing_address": {
    "line1": "[REDACTED]",
    "city": "[REDACTED]",
    "state": "[REDACTED]",
    "postal_code": "[REDACTED]"
  },
  "status": "paid",
  "issued_date": "2026-06-15"
}

// middleware/authorizeInvoice.js
const authorizeInvoice = async (req, res, next) => {
  const invoice = await Invoice.findById(req.params.invoiceId);

  if (!invoice) {
    return res.status(404).json({ error: "Invoice not found" });
  }

  // Verify org-level ownership
  if (invoice.orgId !== req.auth.organisationId) {
    logger.warn("IDOR attempt", {
      userId: req.auth.userId,
      requestedInvoice: req.params.invoiceId,
      userOrg: req.auth.organisationId,
      invoiceOrg: invoice.orgId
    });
    return res.status(403).json({
      error: "Forbidden: insufficient permissions"
    });
  }

  req.invoice = invoice;
  next();
};

POST /api/v2/auth/token/refresh HTTP/1.1
Host: api.acmesaas.io
Content-Type: application/json
Authorization: Bearer eyJ0eXAi...[EXPIRED ACCESS TOKEN]

{
  "refresh_token": "rt_[REDACTED]...expired_8_days_ago"
}

{
  "access_token": "eyJ0eXAi...[NEW VALID TOKEN]",
  "token_type": "Bearer",
  "expires_in": 900
}

async function refreshToken(req, res) {
  const { refresh_token } = req.body;

  // 1. Validate refresh token exists and is not expired
  const storedToken = await RefreshToken.findOne({
    token: refresh_token,
    expiresAt: { $gt: new Date() },
    revoked: false
  });

  if (!storedToken) {
    return res.status(401).json({ error: "Invalid or expired refresh token" });
  }

  // 2. Verify user account is still active
  const user = await User.findById(storedToken.userId);
  if (!user || !user.isActive) {
    await RefreshToken.revokeAll(storedToken.userId);
    return res.status(401).json({ error: "Account deactivated" });
  }

  // 3. Check if password changed after token was issued
  if (user.passwordChangedAt > storedToken.issuedAt) {
    await RefreshToken.revokeAll(storedToken.userId);
    return res.status(401).json({ error: "Password changed, re-authenticate" });
  }

  // 4. Rotate: revoke old token, issue new pair
  await storedToken.revoke();
  const newTokens = generateTokenPair(user);
  return res.json(newTokens);
}

Retest Results

How a retest report differs from the first report.

Both pentest plans include a free retest within one month of the v1.0 initial report. The retest verifies every original finding against the current state of the application and confirms whether remediation is effective. The retest completes in 1 to 3 business days on our side, with no extra charge. The updated report (v2.0) is issued at retest close.

Retest

Date: 14 August 2026 (completed in 3 business days). Conducted by: Rathnakara GN.

The Acme SaaS engineering team deployed fixes for all 13 findings across two release cycles within the 30-day remediation window. The retest verified each finding against the current state of the application. All 13 findings were confirmed Remediated.

Remediation SLA Tracking

The table below records, for each finding, the date it was fixed and the number of days that took against Acme SaaS's remediation SLA. The clock starts at the v1.0 report date (17 July 2026), when every finding was communicated. The SLA targets are Critical 7 days, High 14 days, Medium 30 days, and Low or Info 90 days. SOC 2 and ISO 27001 do not set specific remediation deadlines; they require you to define an SLA and evidence that you met it. These targets are Acme SaaS's own policy, shown here as an example. This doubles as evidence that the vulnerability-management control operated: every finding was remediated inside its target, which is what a SOC 2 or ISO 27001 auditor tests.

Compliance Evidence Package

The tables below map all pentest findings to relevant SOC 2 and ISO 27001 controls. This section is formatted for direct inclusion in your audit evidence package. Hand these tables to your auditor as evidence of penetration testing, findings, and remediation.

Two Trust Services Criteria are evidenced by the engagement itself rather than by any single finding, and they are the primary reason a client's SOC 2 auditor asks for this report. CC4.1 requires that the entity uses separate evaluations to ascertain whether the components of internal control are present and functioning; an independent penetration test is a separate evaluation. CC7.1 requires that the entity uses detection and monitoring procedures to identify vulnerabilities; the testing performed here is that identification step. Both appear as the first rows of the SOC 2 table below. The remaining criteria are evidenced by specific findings and their remediation.

Independence of assessors. This engagement was performed by Cybersecify as an independent third party. The assessors had no role in building, operating, or maintaining the controls under test. That separation is what lets the report serve as separate-evaluation evidence under CC4.1. Whether your CPA firm relies on it in the SOC 2 examination is their judgement under their own professional standards, not something we can promise on their behalf.

A one-page Letter of Attestation (scope, testing dates, methodology, summary result, and retest outcome) is available on request. Clients hand it to auditors or prospects as proof that testing took place, without disclosing the findings themselves. It references the same ISO/IEC 27001:2022 Annex A controls (A.8.8, A.8.29) and SOC 2 criteria used in this report.

SOC 2 Control Mapping

The SQL injection finding (CS-2026-002) is mapped to CC7.1. CC6.1 through CC6.7 cover logical and physical access boundaries; an application-layer injection flaw is not a boundary control, so it is evidenced under vulnerability detection (CC7.1) and its parameterized-query fix under change management (CC8.1) rather than under CC6.6.

ISO/IEC 27001:2022 Annex A Control Mapping

Control references use ISO/IEC 27001:2022 Annex A numbering. The 2013 to 2022 transition deadline passed in October 2025, so current certificates use the 2022 controls.

The last two rows are evidenced by the engagement rather than by any single finding, and they are the two an ISO 27001 auditor asks for first. A.8.29 covers security testing in development and acceptance and is evidenced by the test itself, performed against the scope and methodology recorded in Section 2. A.8.8 covers management of technical vulnerabilities and is evidenced by the findings register, the severity ratings, and the dated remediation trail in Section 5. A.8.25 secure development life cycle is not claimed here: it is evidenced by your development process, not by a test report.

Appendix

A. Tools

Each engagement records the exact tool versions in use at the time. Versions vary by engagement and are captured in the live report shared with the client. The list below covers the tools we routinely use during a Growth Pentest Plan engagement.

B. Testing Team Credentials

C. Report Distribution

D. Glossary

Disclaimer

Penetration testing is inherently limited by the scope, time, and resources allocated to the engagement. Therefore, no individual or organization can guarantee identifying all security issues. The testing we performed is conducted on a best-effort basis, and the findings reported herein are specific to the environment provided for testing.

The dynamic nature of technology and the constant evolution of new attack techniques mean that security assessments can only provide a snapshot of the current security posture.

Limitations of Testing

The reported findings apply exclusively to the tested environment and configurations during testing. Information systems rely on human factors and can be inherently vulnerable to human error. While we have endeavoured to identify significant security vulnerabilities in the analysed applications, it is impossible to assure that all potential vulnerabilities have been discovered.

Scope of Findings

The recommendations provided are based on the information, technologies, and known threats as of the date of this report. As technologies and risks evolve, so will the nature of vulnerabilities and the necessary mitigation measures.

Continued Vigilance

Security is an ongoing process. Regular assessments and updates to security measures are essential to maintaining a strong security posture. We recommend periodic penetration testing and continuous monitoring to adapt to new threats and vulnerabilities.

By accepting this report, you acknowledge the testing's inherent limitations and understand the necessity of ongoing security vigilance.