Extract data from penetration test reports

A penetration test report is the deliverable a security firm hands a client after trying to break into its systems on purpose. Halcyon Payments Inc. commissions Verita Security Labs to attack its cardholder environment for three weeks, and what comes back is a 60-page PDF: an executive summary, a scope statement, a severity-ranked list of every vulnerability the testers reached, and a remediation plan with owners and deadlines. Security, GRC, and engineering leads each read a different slice of it. The CISO wants the overall risk rating and the count of critical findings; the assessor wants the compliance mapping; the engineers want the affected system, the CVSS vector, and the fix for each finding. That information is scattered across prose, callout boxes, and appendix tables, and no two firms format it alike. The engagement ran from 2026-05-04 to 2026-05-22 and closed 19 findings: 2 critical, 5 high, 8 medium, and 4 low, with an overall risk rating of High and a data-compromise risk of High. The methodology section cites the OWASP Testing Guide, PTES, and NIST SP 800-115, with severities scored on CVSS 3.1, and the scope was an authenticated gray-box assessment of the payment API and its supporting infrastructure, explicitly excluding the third-party fraud-scoring vendor. A single critical finding, an SQL injection in the /v2/refunds endpoint scored CVSS 9.1, carries a remediation deadline of 2026-06-05, while two of the medium findings are flagged as recurring from the prior year's assessment. Compliance standards assessed include PCI-DSS 4.0, SOC 2, and ISO 27001. Talonic reads the report and returns the header metadata, the severity counts, and the risk ratings as fields, and the vulnerability register, the tested systems, and the remediation actions as tables, each vulnerability carrying its CVSS score, affected system, and authentication requirement. It reports the findings exactly as the testers wrote them: it does not run its own scan, re-score a CVSS value, or advise which fix to prioritize. The severity counts are checked to foot to the total finding count, so a report that claims 19 findings but lists 21 rows is caught on ingest rather than trusted.

What gets extracted from penetration test reports

How extraction works for penetration test reports

Penetration test reports are exported from tools such as Dradis or PlexTrac or from a consultant's own template, and the same facts appear under different headings from one firm to the next. Talonic classifies the report and aligns it to the security-assessment schema held in the Field Registry, so the client name, the tester, the test period, the overall risk rating, and the four severity counts each resolve to a stable field regardless of the source layout. The vulnerability register loads as a table keyed by vulnerability_id, with the title, CVSS score, affected system, and authentication_required flag preserved per row, and the remediation_actions table keeps each action tied to its finding_id, priority, and target completion date. Dates such as the 2026-05-22 test end and the 2026-06-05 remediation deadline parse to ISO 8601. Every value carries a confidence score and a pointer back to its source region under DIN SPEC 91491, so an engineer can jump from an extracted CVSS 9.1 straight to the paragraph that reported it. Talonic captures the assessment as written and performs no testing, scoring, or remediation judgment of its own.

Sample extraction

A gray-box penetration test report for a payments API

{
  "document_number": "PT-2026-0416",
  "document_date": "2026-05-29",
  "test_period_start_date": "2026-05-04",
  "test_period_end_date": "2026-05-22",
  "client_name": "Halcyon Payments Inc.",
  "tester_name": "Verita Security Labs",
  "overall_risk_rating": "High",
  "critical_findings_count": 2,
  "high_findings_count": 5,
  "medium_findings_count": 8,
  "low_findings_count": 4,
  "total_findings_count": 19,
  "methodology": "OWASP Testing Guide, PTES, NIST SP 800-115; severities scored on CVSS 3.1",
  "testing_type": "gray-box",
  "assessment_scope_type": "API",
  "compliance_standards": "PCI-DSS 4.0, SOC 2, ISO 27001",
  "data_compromise_risk": "High",
  "recurring_finding_count": 2,
  "remediation_deadline": "2026-06-05",
  "vulnerabilities": [
    {
      "vulnerability_id": "VULN-001",
      "title": "SQL injection in /v2/refunds endpoint",
      "severity": "Critical",
      "cvss_score": 9.1,
      "affected_system": "payment-api",
      "remediation": "Parameterize the refund query and add input validation",
      "authentication_required": false
    },
    {
      "vulnerability_id": "VULN-002",
      "title": "Broken access control on admin console",
      "severity": "High",
      "cvss_score": 8.2,
      "affected_system": "admin-portal",
      "remediation": "Enforce role checks server-side",
      "authentication_required": true
    }
  ],
  "risk_summary": [
    {
      "severity_level": "Critical",
      "finding_count": 2,
      "percentage_of_total": 10.5,
      "remediation_priority": "Immediate"
    },
    {
      "severity_level": "High",
      "finding_count": 5,
      "percentage_of_total": 26.3,
      "remediation_priority": "Urgent"
    }
  ]
}

Frequently asked