---
title: "PCI DSS Compliance"
description: "How Alastor InfoSec supports PCI DSS compliance — required penetration testing, network segmentation validation, and continuous evidence for cardholder data environments."
keywords:
  - PCI DSS compliance
  - PCI DSS penetration testing
  - cardholder data environment
  - PCI DSS v4
  - payment security compliance
---

# PCI DSS Compliance

The Payment Card Industry Data Security Standard is one of the few compliance frameworks that explicitly mandates penetration testing rather than just implying it — if you store, process, or transmit cardholder data, PCI DSS requires regular, structured testing of your cardholder data environment (CDE), not just general security hygiene.

## What PCI DSS Actually Requires

- **Annual and post-change penetration testing** — both internal and external testing of the CDE, plus testing after any significant infrastructure or application change.
- **Network segmentation validation** — if you rely on segmentation to reduce PCI scope, that segmentation itself has to be tested and proven effective, not just assumed.
- **Quarterly vulnerability scanning** — by an Approved Scanning Vendor (ASV) for external-facing systems in scope.
- **Strong access control and encryption requirements** for cardholder data at rest and in transit, with strict requirements around key management.

PCI DSS v4.0 raised the bar further, with an increased emphasis on continuous, risk-based security rather than point-in-time compliance — the standard's own direction is moving toward exactly the continuous model Alastor InfoSec is built around.

## Where Alastor InfoSec Fits

[Alastor Pulse](/products/alastor-pulse) delivers PCI-scoped penetration testing on the cadence the standard actually requires — annual and post-change testing, with segmentation validation included, and findings that map directly to PCI DSS requirements instead of a generic pentest report your QSA has to manually cross-reference.

[Alastor Shield](/products/alastor-shield) handles the ongoing evidence trail between assessments: vulnerability scan history, access control documentation, and change-driven testing records, so your annual Report on Compliance (RoC) or Self-Assessment Questionnaire (SAQ) doesn't require reconstructing a year of activity from scattered spreadsheets.

## Common Gaps We See

- **Segmentation assumed, never tested** — reducing PCI scope on paper without penetration testing evidence that the segmentation actually holds.
- **Testing that happens once a year and stops** — missing the required retest after a significant CDE change mid-cycle.
- **Vulnerability scans and pentests treated as unrelated activities** — instead of one continuous testing program that satisfies both requirements together.

## Who Needs This

Any business that stores, processes, or transmits cardholder data — e-commerce platforms, payment processors, fintechs, and any merchant or service provider handling card transactions — falls under PCI DSS, with scope and assessment level (SAQ vs. full RoC) determined by transaction volume and how card data is handled.

[Talk to our team](/about-us) about scoping PCI DSS-aligned penetration testing for your cardholder data environment.