PCIScopeBoundary — PCI-DSS CDE Scope + Boundary Attestation
22 systems classified by PCI-DSS scope: in-CDE, connected-to-CDE (segmented), out-of-scope. Per system: PAN/CHD touchpoints, network segmentation evidence, segmentation test status, control owner. Surfaces 2 scope-leaked systems + 1 missing annual segmentation test (Req 11.4).
What it is
The scope-boundary register every QSA pulls first. PCI scope creep is silent + cumulative — a system that was out-of-scope last year suddenly touches a token, and now an entire VPC is in scope.
What’s in it
- 22 systems classified into 4 scope tiers (in-CDE, connected, out-of-scope, scope-leaked)
- Per system: role, PAN/CHD touchpoints, segmentation evidence, segmentation test date, owner
- Worst-offender: PS-018 schema-change exposed last4 to BI for 4h (cross-references IncidentLog SC-013); PS-019 dormant refund-tool with payment-DB access (caught by AccessReview); PS-022 customer-X dedicated stack with overdue annual segmentation test
Why this shape
PCI-DSS v4.0 Req 11.4 mandates annual segmentation testing. The PCI Scoping Toolkit 2024 defines the in-CDE / connected / out-of-scope taxonomy. The hard finding: a scope-leak between assessments that nobody noticed.
How it ships
Single HTML file, ~13KB. Zero dependencies. 22 systems × scope/status filters + per-system attestation in 100 lines of vanilla JavaScript.