§ PCI DSS 4.0

Pentest the CDE. Prove segmentation. Retain everything.

PCI DSS 4.0 requires defined methodology, internal and external penetration testing, segmentation testing, and remediation tracking — all evidenced. SecHive turns that list into a single auditable bundle.

Book a compliance demo → How the chain works

FrameworkPCI DSS 4.0

JurisdictionPCI SSC

ReferenceRequirement 11.4 (and 6.4)

ScopeCardholder-data environment

SecHive evidencetechnical

Auditor opinionout of scope

§ Articles → Evidence

Where SecHive evidence fits in PCI DSS 4.0.

The mapping is intentionally narrow. We list only the articles where SecHive produces a directly defensible artifact, and we name the artifact.

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.

§ Buyer view

SecHive provides.

What you can put in front of an auditor or a security review.

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 stamped on every disposition.
Cosigned attestation on report bundles.

For engineering

Deterministic replay.sh per 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…
  signed:  cosign:sechive-key
disposition:
  reviewer:  redacted-operator
  state:    confirmed
retest:
  status:    fixed @ 2026-04-18
  evidence:  artifacts/retest-receipt.json

What an auditor 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.

See the full output matrix →