Sample Deliverables

See What a Real, Audit-Ready Pen Test Looks Like

Not a generic PDF. Real findings, real evidence, real verification. Download sample deliverables to see the Opsfolio difference.

  • Executive and engineering-ready reports
  • Retest verification with before/after evidence
  • Compliance mappings for SOC 2, ISO 27001, CMMC
  • Professional Rules of Engagement template

Get Instant Access

Fill out the form to download

We respect your privacy. No spam, ever.

What you'll receive:

  • Sample penetration testing report with real findings
  • Rules of Engagement template for your engagements
  • Compliance mapping examples (SOC 2, ISO, CMMC)

What You'll Receive

Sample Penetration Testing Report

A complete sample report showing our methodology, finding format, evidence quality, and compliance mapping approach.

  • Executive summary for leadership
  • Detailed findings with remediation
  • Compliance control mappings

Rules of Engagement Template

A professional RoE template that demonstrates our commitment to safety, clarity, and professional engagement practices.

  • Scope and authorization sections
  • Testing constraints and protocols
  • Communication and escalation

Sample Penetration Testing Report

Review the full sample report below to understand our methodology, finding format, and evidence quality.

SAMPLE DOCUMENT

Penetration Testing Report

Human-Led Offensive Security with Audit-Ready Evidence

SAMPLE / DEMONSTRATION DOCUMENT

Client

Sample Company
(Mid-Market SaaS)

Assessment Type

Web Application
Penetration Test

Testing Period

November 4-15, 2024

Prepared By

Opsfolio Security Team

CONFIDENTIAL - This document contains sensitive security information. Distribution is limited to authorized personnel only. Sample document for evaluation purposes.

Executive Summary

Overall Security Posture

Moderate Risk

Total Findings

7

Remediated & Verified

5 of 7

Key Risk Themes

Authorization Controls

Object-level access controls require strengthening to prevent unauthorized data access.

Session Management

Session token generation could be improved to meet current security standards.

Information Disclosure

Error handling reveals implementation details that could aid attackers.

Strong Foundations

Authentication mechanisms and transport security are well-implemented.

Compliance Implications

The identified findings have relevance to SOC 2 Trust Service Criteria (CC6.1, CC6.6, CC7.2), ISO 27001 Annex A controls, and CMMC access control practices. Remediation of the high-severity authorization finding is recommended before the upcoming SOC 2 Type II audit window.

Scope and Rules of Engagement

In-Scope Assets

  • app.samplecompany.com - Primary web application
  • api.samplecompany.com - REST API endpoints (v2)
  • User authentication and authorization flows
  • File upload and document management features

Out of Scope

  • Production database (read-only test accounts used)
  • Third-party integrations (Stripe, SendGrid)
  • Social engineering and physical security
  • Denial of service testing

Testing Window

Nov 4-15, 2024

Testing Hours

09:00-18:00 EST

Testing Team

2 Senior Consultants

Methodology

1

Scoping & Preparation

Define objectives, scope, and rules of engagement

2

Reconnaissance

Information gathering and attack surface mapping

3

Testing & Validation

Manual and tool-assisted vulnerability identification

4

Evidence Capture

Document findings with reproducible evidence

5

Reporting

Risk-ranked findings with remediation guidance

6

Retest & Verification

Validate fixes and produce verification artifacts

Our methodology combines manual expert analysis with tool-assisted scanning. All findings are manually validated to eliminate false positives. When available, we incorporate design documentation and code context to provide more targeted testing and accurate remediation guidance.

Findings Overview

IDTitleSeverityStatus
WEB-001Insecure Direct Object Reference in User API
High
Verified
WEB-002Session Token Predictability
Medium
Verified
WEB-003Verbose Error Messages Exposing Stack Traces
Low
Open

0

Critical

1

High

2

Medium

4

Low / Info

Detailed Findings

WEB-001
High
Remediated & Verified

Insecure Direct Object Reference in User API

Description

The user profile API endpoint accepted user IDs as direct parameters without proper authorization validation. An authenticated user could modify the ID parameter to access or modify other users' profile information, including email addresses and account settings.

Business Impact

This vulnerability could allow unauthorized access to customer PII, potential account takeover scenarios, and regulatory compliance violations under GDPR, CCPA, and HIPAA. Exploitation would likely result in mandatory breach notification requirements.

Steps to Reproduce

1. Authenticate as User A and capture a valid session token

2. Send a GET request to /api/v2/users/{USER_B_ID}

3. Observe that User B's profile data is returned

[Evidence: Screenshot and request/response logs redacted]

Recommended Remediation

Implement server-side authorization checks to verify the authenticated user has permission to access the requested resource. Use session-bound user context rather than user-supplied IDs for ownership verification. Consider implementing UUID-based identifiers to reduce enumeration risk.

Retest Note: Verified on November 18, 2024. Authorization checks now properly enforce user-resource ownership. Attempted access to other users' profiles returns 403 Forbidden.

WEB-002
Medium
Remediated & Verified

Session Token Predictability

Description

Session tokens were generated using a time-based algorithm with insufficient entropy. Analysis of multiple tokens revealed a predictable pattern that could potentially allow an attacker to guess valid session identifiers.

Business Impact

While exploitation requires significant effort, successful session prediction could lead to account takeover without requiring credentials. This represents a medium-term risk that should be addressed to maintain security posture.

Recommended Remediation

Replace the current token generation mechanism with a cryptographically secure random number generator (CSPRNG). Ensure tokens have at least 128 bits of entropy. Consider implementing token binding to further reduce session hijacking risks.

Retest Note: Verified on November 19, 2024. Token generation now uses crypto.randomBytes() with 256-bit entropy. Statistical analysis confirms no predictable patterns.

WEB-003
Low
Open

Verbose Error Messages Exposing Stack Traces

Description

Application errors return detailed stack traces and internal path information to end users. While not directly exploitable, this information disclosure aids attackers in understanding the application architecture and identifying potential attack vectors.

Recommended Remediation

Implement a global error handler that returns generic error messages to users while logging detailed information server-side. Ensure production environment variables are properly configured to disable debug mode.

Status: Scheduled for remediation in next sprint. Risk accepted for current release cycle due to low severity and defense-in-depth controls.

Opsfolio Evidence Pack

All artifacts from this engagement are stored in Opsfolio as structured, auditor-ready evidence. This Evidence Pack can be used for SOC 2, ISO 27001, CMMC, and other compliance audits.

Signed Rules of Engagement

Authorization and scope documentation

Tester Identity & Timing

Who tested, when, and from where

Timestamped Findings

All findings with unique IDs and timestamps

Evidence Screenshots

Proof of findings (redacted as needed)

Remediation Verification

Before/after evidence for retests

Risk Acceptance Records

Documentation for accepted risks

Compliance Support Mapping

FindingSOC 2ISO 27001CMMC
WEB-001CC6.1 (Logical Access)A.9.4.1 (Access Restriction)AC.L2-3.1.1
WEB-002CC6.6 (System Operations)A.14.1.2 (Secure Development)IA.L2-3.5.2
WEB-003CC7.2 (System Monitoring)A.12.6.1 (Technical Vulnerabilities)SI.L2-3.14.1

Disclaimer: Control mappings are provided as guidance to support audit preparation. They do not constitute certification or guarantee compliance. Consult with your auditor for authoritative mapping decisions.

Conclusion and Next Steps

This assessment identified security concerns primarily related to authorization controls and session management. The development team has addressed the high and medium severity findings, with verification confirming effective remediation.

Recommended Next Steps

  • 1.Complete remediation of remaining low-severity finding (WEB-003)
  • 2.Implement SAST/DAST in CI/CD pipeline for continuous security validation
  • 3.Schedule quarterly penetration testing to maintain security posture
  • 4.Consider API-specific assessment for the upcoming v3 release

Opsfolio recommends annual comprehensive assessments with quarterly targeted testing aligned to major releases. Contact your account team to discuss continuous testing arrangements.

Rules of Engagement Template

Review our professional RoE template to understand how we structure engagements for safety, clarity, and compliance.

TEMPLATE

Rules of Engagement

Penetration Testing Authorization Template

TEMPLATE DOCUMENT - CUSTOMIZE FOR YOUR ENGAGEMENT

This template provides a framework for establishing rules of engagement for penetration testing engagements. Customize all bracketed fields for your specific environment.

1. Purpose and Objectives

1.1 Purpose

This document establishes the rules of engagement for a penetration testing assessment of [CLIENT ORGANIZATION NAME]'s systems and applications. It defines the scope, constraints, and protocols that govern the testing activities.

1.2 Objectives

  • Identify security vulnerabilities in the defined scope
  • Assess the potential impact of identified vulnerabilities
  • Provide actionable remediation recommendations
  • Produce compliance-ready evidence artifacts
  • Support [COMPLIANCE FRAMEWORK(S)] requirements

1.3 Success Criteria

This engagement will be considered successful upon delivery of a comprehensive report containing identified findings, risk assessments, remediation guidance, and supporting evidence suitable for audit purposes.

2. Authorization and Approvals

IMPORTANT: Testing may only commence after this document has been signed by an authorized representative of the client organization with appropriate authority to authorize security testing activities.

2.1 Authorization Statement

"[CLIENT ORGANIZATION NAME] hereby authorizes [TESTING ORGANIZATION] to perform penetration testing activities against the systems and applications defined in the Scope section of this document, during the testing window specified herein."

2.2 Authorized Signatories

Client Approver

[NAME]

[TITLE]

[DATE]

Signature:

Testing Lead

[NAME]

[TITLE]

[DATE]

Signature:

2.3 Emergency Contacts

Primary Contact

[NAME]

[PHONE]

[EMAIL]

Escalation Contact

[NAME]

[PHONE]

[EMAIL]

3. Scope Definition

3.1 In-Scope Assets

Domain/Application

[app.example.com]

Description: [Primary web application]

API Endpoint

[api.example.com]

Description: [REST API v2 endpoints]

IP Range

[192.168.1.0/24]

Description: [Internal network segment]

Add additional rows as needed for your scope.

3.2 Out-of-Scope

  • Production databases (read-only access only)
  • Third-party services: [LIST]
  • Physical security testing
  • Social engineering (unless explicitly approved)
  • Denial of service attacks
  • Data exfiltration beyond proof of concept

3.3 Environment Details

Production

[Read-only / Limited / Full]

Staging

[Read-only / Limited / Full]

Development

[Read-only / Limited / Full]

4. Testing Constraints

4.1 Allowed Techniques

  • Passive and active reconnaissance
  • Vulnerability scanning (with rate limiting)
  • Manual exploitation of identified vulnerabilities
  • Authentication testing (provided credentials)
  • Business logic testing
  • API security testing

4.2 Prohibited Techniques

  • Denial of service (DoS/DDoS) attacks
  • Physical intrusion or social engineering
  • Attacks against third-party infrastructure
  • Data destruction or modification
  • Installation of persistent backdoors
  • Exfiltration of real customer data

4.3 Rate Limiting and Safety Controls

Maximum scan rate:

[X requests/second]

Concurrent connections:

[X maximum]

5. Testing Window and Coordination

Start Date

[DATE]

End Date

[DATE]

Testing Hours

[HH:MM - HH:MM TZ]

Timezone

[UTC/EST/PST]

5.1 Change Freeze Awareness

Testing team will be notified of any scheduled maintenance, deployments, or change freeze periods that may affect testing activities.

5.2 Incident Response Coordination

If testing activities trigger security alerts or incident response procedures, the testing team will [coordinate with / notify] the client's security operations team via [METHOD].

6. Data Handling and Confidentiality

6.1 Sensitive Data Handling

  • • Any sensitive data encountered will be documented minimally for proof of finding
  • • No real customer PII will be extracted or stored beyond screenshots
  • • All evidence will be encrypted in transit and at rest
  • • Access to findings is limited to authorized personnel

6.2 Redaction Policy

All reports and evidence artifacts will redact: personally identifiable information (PII), credentials, API keys, and any data that could enable unauthorized access if disclosed.

6.3 Retention Period

Testing artifacts will be retained for [X months/years] in secure storage. Upon expiration, all materials will be securely deleted with written confirmation.

6.4 Evidence Storage

All evidence is stored in Opsfolio's secure evidence management system with role-based access controls, audit logging, and encryption. Evidence artifacts are available for compliance audits upon authorized request.

7. Communication and Escalation

7.1 Regular Communication

  • • Daily status updates via [EMAIL/SLACK/OTHER]
  • • Weekly sync calls at [DAY/TIME]
  • • Final readout meeting upon completion

7.2 Critical Finding Notification

Critical or high-severity findings that pose immediate risk will be reported within [X hours] of discovery via:

  • • Phone: [PRIMARY CONTACT NUMBER]
  • • Email: [SECURITY@DOMAIN.COM]

7.3 Emergency Stop Procedure

Either party may invoke an emergency stop at any time by contacting the designated emergency contact. Testing will cease immediately upon notification and will not resume until both parties agree in writing.

7.4 Points of Contact

Client Side

Primary: [NAME]

Technical: [NAME]

Executive: [NAME]

Testing Side

Lead Tester: [NAME]

Project Manager: [NAME]

Escalation: [NAME]

8. Retest Expectations

8.1 Retest Conditions

Retesting of remediated findings is included for [HIGH/CRITICAL] severity findings within [X days] of the client notifying completion of remediation.

8.2 Verification Criteria

  • • The original attack vector is no longer exploitable
  • • The remediation does not introduce new vulnerabilities
  • • Evidence of successful remediation is documented

8.3 Documentation

Retest results will be documented in an addendum to the original report, including before/after evidence and updated finding status. All retest evidence will be stored in the Opsfolio Evidence Pack.

9. Legal and Compliance Notes

Disclaimer: This template is provided for informational purposes. Organizations should consult with legal counsel to ensure compliance with applicable laws and regulations in their jurisdiction.

9.1 Authorization Scope

All testing activities are performed with explicit written authorization from the client organization. Testing will be conducted only against assets explicitly included in the defined scope.

9.2 Compliance Alignment

This engagement is designed to support compliance with [FRAMEWORK(S)] requirements. Findings and evidence artifacts will be structured to facilitate audit preparation. Note: Penetration testing supports but does not guarantee compliance.

9.3 Limitation of Liability

Standard limitation of liability terms as defined in the Master Services Agreement apply to this engagement. Both parties agree to handle any disputes through [ARBITRATION/MEDIATION/JURISDICTION].

9.4 Good Faith Clause

Both parties agree to act in good faith throughout this engagement. The testing organization will exercise reasonable care to avoid disruption to business operations, and the client organization will provide reasonable access and support for testing activities.

Acceptance and Signatures

By signing below, both parties acknowledge and agree to the terms and conditions outlined in this Rules of Engagement document.

Client Organization

Authorized Representative

Title

Date

Signature

Testing Organization

Authorized Representative

Title

Date

Signature

Ready to Get Started?

Now that you've seen what audit-ready pentesting looks like, let's discuss how we can help secure your environment.