Penetration Test Reporting Questions

Covers how to structure and communicate the results of a penetration test for multiple stakeholders. Includes preparing an executive summary with high level findings and risk ratings, a clear scope and constraints section, an explicit methodology and testing timeline, prioritized technical findings with evidence such as screenshots and proof of concept, vulnerability severity and impact assessments (for example using common scoring frameworks), recommended remediations with suggested priorities and verification steps, risk acceptance and mitigation options, and appendices containing raw logs, exploit details, remediation validation procedures, and legal or compliance notes. Also includes tailoring language and detail level for technical teams, security leadership, and nontechnical executives while preserving accuracy and traceability.

MediumTechnical

53 practiced

Describe a practical approach to ensure traceability between each finding and its supporting artifacts (screenshots, PCAPs, logs), timeline entries and the tester who produced them. Include naming conventions, a manifest file schema or table example, preferred file formats, and how to present these references in the report so auditors and engineers can verify chain-of-evidence.

Sample Answer

**Approach overview**I ensure a verifiable chain-of-evidence by enforcing strict naming conventions, storing metadata in a manifest (machine- and human-readable), using forensic-safe file formats, and linking each finding to artifacts and the tester in the report.

**Naming convention (example)**- Format: ENG-YYYYMMDD-TSTnn-FINDnn-ARTTYPE-SEQ.ext - Example: ACME-20250315-TST02-FIND03-SHOT-01.png - ENG = engagement code, TST = tester ID, FIND = finding number, ARTTYPE = SHOT/PCAP/LOG/EXP, SEQ = sequence

**Manifest schema (JSON, example)**

text

{
  "engagement_id": "ACME-20250315",
  "tester_id": "TST02",
  "artifacts": [
    {
      "artifact_id": "ACME-20250315-TST02-FIND03-SHOT-01",
      "finding_id": "FIND03",
      "type": "screenshot",
      "filename": "ACME-20250315-TST02-FIND03-SHOT-01.png",
      "sha256": "hexhash",
      "timestamp_utc": "2025-03-15T10:12:34Z",
      "tool": "Burp Suite",
      "notes": "Login bypass proof"
    }
  ]
}

**Preferred formats & handling**- Screenshots: PNG (lossless), 24-bit- PCAPs: pcapng (with comments)- Logs: UTF-8 UTF-8 newline, .log or .txt; for system logs include original timestamps- Hashes: SHA-256 for each file; store hashes in manifest- Storage: read-only archive (zip signed or write-protected), with timestamps and access logs

**Report presentation**- For each finding include: brief description, impact, steps to reproduce, and a “Evidence” block listing artifact IDs, filenames, timestamps, SHA-256, and direct hyperlinks to files in the archive. Example: - Evidence: ACME-20250315-TST02-FIND03-SHOT-01.png (sha256: xxx, 2025-03-15T10:12Z), ACME-...-PCAP-01.pcapng- Provide the manifest as appendix and downloadable machine-readable file for auditors- State chain-of-custody: who collected (tester ID), when, and storage controls

This guarantees reproducibility, fast verification, and audit-ready traceability.

HardSystem Design

53 practiced

Design an end-to-end secure report distribution and artifact storage architecture for sensitive penetration test reports and PoC artifacts. Requirements: role-based access control, encryption at rest and in transit, tamper-evident audit logs, short-lived access links for vendors, retention policy, and ease-of-use for clients. Describe components, key management approach, authentication, and data flow; name candidate technologies you would use.

Sample Answer

**Overview & goals**Design a secure pipeline to store and distribute penetration test reports and PoC artifacts with RBAC, end-to-end encryption, tamper-evident logs, short-lived vendor links, retention enforcement, and client usability.

**Components**- Storage: Object store (S3/GCS) in a private bucket + server-side encryption disabled for client-side envelope encryption.- Metadata & access service: API (FaaS/container) managing RBAC, presign logic, retention.- KMS: Dedicated KMS (AWS KMS / Google Cloud KMS / HashiCorp Vault) with Envelope Encryption and HSM-backed keys.- Authn/Z: Identity provider (OIDC) + IAM groups/roles; optional SCIM sync for clients.- Audit logs: Immutable WORM logs (AWS CloudTrail + S3 Object Lock or append-only journals in write-once DB like DynamoDB with streams) and SIEM (Splunk/Elastic).- Client portal: Web UI with 2FA and client-side decryption helper (or automatic via TLS+server-side decryption tied to KMS policy).- Secrets & artifact signing: Use sigstore/cosign or PGP signatures for PoC artifacts.

**Key management**- Envelope encryption: generate per-file DEK; DEK encrypted by KMS CMK.- CMKs in HSM; rotate yearly; split roles (operators vs. testers).- Use key-access policies that require MFA & contextual conditions (IP, time).

**Authentication & RBAC**- OIDC for users (Okta/Auth0/Azure AD); roles: Tester, Client-Viewer, Vendor, Auditor.- Policies enforced in API and KMS IAM. Vendor short-term roles issued via OAuth2 client credentials or AWS STS assuming role for X hours.

**Data flow**1. Tester uploads report to portal; client-side or API encrypts file with generated DEK; DEK wrapped by KMS.2. Store encrypted object and metadata (owner, retention expiry, signature).3. Audit event (upload, decrypt attempts) logged immutably.4. When client requests access, portal verifies RBAC, issues short-lived pre-signed URL (5–60 min) or temporary STS credentials; decryption performed server-side only if KMS policy allows the requester.5. For vendor sharing, create one-time access token with limited scope and expiry; access requires 2FA and logs.

**Retention & tamper-evidence**- Enforce retention via Object Lock/Governance; retention metadata in signed DB records.- Sign artifacts and metadata; store signatures alongside objects.- Audit logs stored in WORM, forwarded to SIEM; alerts for policy violations.

**Candidate technologies**- Storage: AWS S3 (Object Lock), GCP Cloud Storage, Azure Blob- KMS/HSM: AWS KMS / Cloud KMS / HashiCorp Vault (HSM)- IAM/IdP: Okta / Azure AD / Auth0- Short-lived tokens: AWS STS / OAuth2 JWT- Logging/SIEM: CloudTrail + Splunk/Elastic- Signing: cosign/sigstore or PGP- Portal: React + backend serverless (Lambda/Fargate) with strict CSP and CSPRO.

This balances strong cryptographic controls, auditable ops, and smooth client UX while minimizing exposure via short-lived credentials and immutable logging.

MediumTechnical

62 practiced

Compare CVSS v3.x and the OWASP Risk Rating Methodology in the context of penetration test reporting. For each framework, summarize strengths and weaknesses, explain which situations or stakeholders favor one over the other, and propose a practical mapping or conversion heuristic for teams that have to report using both systems.

Sample Answer

**Overview (purpose)** CVSS v3.x is a technical, standardized severity score for individual vulnerabilities. OWASP Risk Rating is a business-contextual method that combines likelihood and impact across technical, business, and detection factors. Both are useful in pentest reporting for different audiences.

**CVSS v3.x — Strengths & Weaknesses** - Strengths: Repeatable, well-adopted, scanner-friendly, precise component metrics (AV/AC/PR/UI/Scope/Impact). Good for technical triage and automation. - Weaknesses: Lacks business context (asset value, business impact); can mislead if used alone to prioritize fixes.

**OWASP Risk Rating — Strengths & Weaknesses** - Strengths: Incorporates business impact, exploitability, prevalence, and detectability; flexible and communicative for stakeholders (product owners, risk teams). - Weaknesses: More subjective; less standardized; harder to automate across many findings.

**Which to use / Stakeholders** - Use CVSS for technical teams, patching workflows, and vulnerability management systems. - Use OWASP Risk Rating when presenting business impact to product owners, security leadership, or when prioritization must reflect asset value and compensating controls.

**Practical mapping / conversion heuristic** 1. Compute base CVSS score. 2. Map CVSS ranges to OWASP likelihood/technical severity: - CVSS 0.1–3.9 → Technical Low; 4.0–6.9 → Technical Medium; 7.0–8.9 → Technical High; 9.0–10 → Technical Critical. 3. Adjust OWASP Impact using asset criticality and data sensitivity: +1 level if asset is business-critical or stores sensitive PII. 4. Adjust Likelihood for public exploit availability or ease (Exploit Code Maturity / Attack Vector in CVSS): downgrade or upgrade one level. 5. Combine into OWASP matrix to produce final Risk (Low/Medium/High/Critical). 6. In reports show both scores and a short rationale line: “CVSS 7.5 (High) mapped to OWASP High due to public exploit and critical customer data.”

**Best practices** - Always include rationale for mapping decisions. - Use CVSS for automation, OWASP for stakeholder prioritization. - Keep mapping rules documented and consistent across engagements.

EasyTechnical

88 practiced

Identify the legal and compliance notices and statements that should appear in a penetration test report. Include examples such as authorization statement, scope of work, liability disclaimers, data handling and retention policy, chain-of-custody notes, and NDA reminders. For each item explain why it is important and provide a short sample phrasing suitable for inclusion in the report.

Sample Answer

**Authorization Statement**- Why: Confirms client consent and legal permission to test.- Sample: “This penetration test was authorized by Acme Corp via written agreement dated 2026-01-10. All testing activities were performed under that authorization and within the agreed scope.”

**Scope of Work**- Why: Prevents accidental overreach and defines systems, IP ranges, time windows, and test types.- Sample: “Scope: External network (203.0.113.0/24), web applications (app.example.com), and internal VLANs A/B during 2026-02-01 to 2026-02-05. Excluded: payroll systems and physical social-engineering.”

**Liability Disclaimer**- Why: Limits tester/firm liability for unintended outages while acknowledging responsibilities.- Sample: “While all reasonable care was taken, [Firm] is not liable for indirect or consequential damages arising from agreed testing; direct negligence will be governed by the Master Services Agreement.”

**Data Handling & Retention**- Why: Protects sensitive data discovered and defines retention/destruction timelines.- Sample: “Sensitive data obtained during testing (credentials, PII) was secured encrypted at rest and will be purged 30 days after report delivery unless client requests otherwise.”

**Chain-of-Custody Notes**- Why: Tracks evidence integrity for legal/forensic purposes.- Sample: “Captured logs and artifacts were stored on hashed, access-controlled media. Hashes: SHA256: abc...; custodian: J. Tester; timestamp: 2026-02-02T14:30Z.”

**NDA / Confidentiality Reminder**- Why: Reminds recipients of confidentiality obligations and distribution limits.- Sample: “This report is Confidential per NDA dated 2026-01-09. Do not distribute outside authorized personnel without written consent.”

**Other: Emergency Contact & Escalation**- Why: Rapid response for critical outages.- Sample: “If testing causes system-critical impact contact: Ops Lead — ops@example.com, +1-555-0100.”

These items protect client and tester, set legal boundaries, and preserve evidence integrity.

HardTechnical

68 practiced

A third-party library you exploited is widely used and the vendor contact is unknown. The client requests coordinated disclosure and possibly a CVE. Describe the steps you would take to coordinate disclosure responsibly: establishing timelines and embargoes, deciding what evidence to share with the vendor, involving legal and product teams, selecting disclosure channels, and mitigating the risk of public exploitation during the disclosure window.

Sample Answer

**Situation & objective** I’d treat this as a high-severity supply-chain disclosure: goal is to protect users, get vendor patch, and optionally obtain a CVE while minimizing public exposure.

**Immediate actions (0–48 hrs)** - Confirm reproducible steps and prepare minimal PoC that demonstrates impact but cannot be weaponized (no full exploit chain). - Record timeline, affected versions, risk rating, and affected assets. - Escalate internally: notify engagement lead, legal, and product/security stakeholders; flag contractual/reporting obligations.

**Coordinated disclosure plan** - Attempt vendor contact via multiple channels: vendor security@, responsible-disclosure pages, WHOIS, OSS maintainers, CERTs, and national CSIRT. If unknown, involve a trusted intermediary (CERT/third-party coordinator). - Propose embargo timeline (e.g., 90 days standard, shorter if active exploitation) and offer staged updates (30/60/90). Be ready to negotiate.

**Evidence sharing & restraint** - Share: affected versions, high-level impact, safe PoC (sanitized), exploitability conditions, recommended mitigations. - Withhold: weaponized exploit code and detailed exploitation steps until patch or CVE assigned.

**Legal & product involvement** - Legal reviews disclosure text, confirms no contract breach and handles liability language. Product/security defines mitigations, compensations, and communication plan for customers.

**CVE & disclosure channels** - Coordinate CVE request via vendor or CERT/mitre if vendor unresponsive. Use coordinated channels: vendor advisory, CERT, Mitre, and controlled release to customers with mitigations first.

**Risk mitigation during embargo** - Recommend immediate mitigations (WAF rules, configuration changes, detection signatures) and provide detection queries/indicators. - Monitor public/underground chatter; shorten embargo if active exploitation is detected.

**Outcome & follow-up** - Maintain clear communication, provide retest of fixes, and publish advisory after patch or mutually agreed date, including CVE and sanitized technical details.

Unlock Full Question Bank

Get access to hundreds of Penetration Test Reporting interview questions and detailed answers.

Join thousands of developers preparing for their dream job.