● FrameworkPCI DSS 4.0PCI SSCRequirement 11.4 (and 6.4)
Compliance / PCI DSS 4.0
§ PCI DSS 4.0
Map authorized testing artifacts to PCI DSS 4.0.
PCI DSS 4.0 includes defined methodology, internal and external penetration testing, segmentation testing, and remediation tracking. This reference shows how technical artifacts may be organized around those topics.
Important boundary. This page is an illustrative reference mapping. Framework references describe evidence mapping and control alignment. SecHive is not presently certified or independently audited under these frameworks unless explicitly stated. This page is not legal advice, evidence that SecHive implements these controls, or a claim that any organization satisfies PCI DSS 4.0.
§ Articles → Evidence
How research artifacts may relate to PCI DSS 4.0.
The mapping is intentionally narrow and illustrative. The final relevance and sufficiency of evidence must be determined by the organization and its qualified assessor.
| Article / control | What it requires | SecHive artifact |
|---|---|---|
| 11.4.1 | Penetration testing methodology defined and followed. | SecHive methodology spine published per engagement; bound to proof pack. |
| 11.4.2 | Internal penetration testing performed at least annually. | Internal-mode runs with scope policy and approval checkpoints. |
| 11.4.3 | External penetration testing at least annually. | External-mode runs with redaction-safe report and retest tracker. |
| 11.4.4 | Exploitable vulnerabilities and security weaknesses corrected. | Per-finding remediation guidance, retest record, and re-attestation. |
| 11.4.5 | Segmentation testing — segmentation methods are operational and effective. | Cross-segment hypothesis testing with traversal evidence and refutation log. |
| 11.4.6 | Service providers — additional segmentation testing every 6 months. | SecHive supports cadence-based reruns of the same proof pack. |
| 6.4.x | Application-layer security testing for public-facing apps. | Web application run mode with API security and source candidate separation. |
§ Review view
How artifacts can be organized.
A practical format for technical review; acceptance by an auditor or assessor is not implied.
For the CISO
- Mappable evidence per Article 21(2) sub-clause.
- Time-bounded findings with severity and impact.
- Retest records that close the loop with the engineering team.
For the legal / compliance team
- Redaction manifests for cross-border or supplier engagements.
- Operator identity recorded on every disposition.
- Artifact hashes on report bundles.
For engineering
- Deterministic
replay.shper finding. - Source references when source mode is enabled.
- Negative evidence for refuted candidates.
For the auditor
- Run-mode-labeled evidence rows.
- sha256 binding to underlying artifacts.
- Methodology spine consistent across engagements.
§ Sample evidence
A page from the matrix.
SecHive renders an evidence matrix per engagement. Below is one row, redacted.
EVIDENCE ROW — sample
# evidence-row.yaml — redacted control: PCI 11.4.5 # effectiveness testing finding_id: VTX-RPL-0042 mode: black-box target: redacted target_ref: image@sha256:9c4e… # pinned artifact: path: artifacts/replay.sh sha256: 7c3a… review: human-approved disposition: reviewer: redacted-operator state: confirmed retest: status: fixed @ 2026-04-18 evidence: artifacts/retest-receipt.json
What a reviewer sees
- The control id and the finding id, bound together.
- A run-mode label (black-box, source-aware, etc.).
- A sha256 of the underlying artifact.
- A reviewer disposition with operator identity.
- A retest record if the finding has been remediated.
Discuss a PCI DSS 4.0 reference mapping.
Bring an authorized scope and the evidence questions you are working through.