PCI-DSS Compliance for Regulated Mid-Market
Any organization that stores, processes, or transmits payment card data has to answer to the Payment Card Industry Data Security Standard. This guide covers what PCI-DSS actually requires, who it applies to, and how Armorstack’s CORE and SENTRY portfolios operationalize the twelve requirements instead of leaving them as a once-a-year audit scramble.
What Is PCI-DSS?
The Payment Card Industry Data Security Standard (PCI-DSS) is a set of technical and operational security requirements developed and maintained by the PCI Security Standards Council — founded by American Express, Discover, JCB International, Mastercard, and Visa — to protect cardholder data. It is not a law, but every major card brand contractually requires merchants and service providers that touch payment card data to comply with it, and the card brands enforce it through the acquiring banks and payment processors in the merchant chain. The current active version is PCI DSS v4.0.1.
Who Actually Has to Comply
PCI-DSS applies to any entity that stores, processes, or transmits cardholder data — the primary account number (PAN), and where present alongside it, cardholder name, expiration date, or service code — or that could impact the security of that data. This is a functional test, not a size test. It reaches:
- Retailers and e-commerce merchants accepting card payments online, in-store, or by phone.
- Financial services and payment processors that route, authorize, or settle card transactions.
- Software and SaaS providers whose platforms store or transmit cardholder data on a merchant’s behalf.
- Service providers such as hosting companies, managed IT providers, and call centers with access to cardholder data or the systems that protect it.
- Any organization — healthcare, manufacturing, education — that accepts card payments for goods or services, even as a secondary line of business.
A common and costly misconception is that outsourcing payment processing to a third party (Stripe, Square, a payment gateway) eliminates PCI-DSS obligations entirely. It reduces scope significantly, but the merchant still has PCI-DSS responsibilities of its own — typically documented through a Self-Assessment Questionnaire. See which SAQ type applies to your setup.
The 12 Core Requirements, at a Glance
PCI-DSS organizes its controls into six goals and twelve numbered requirements. Every SAQ type and every Report on Compliance is scoped against this same structure — only the depth of evidence required changes.
Install and maintain network security controls; apply secure configurations to all system components and remove vendor-default passwords and settings.
Protect stored account data through encryption, truncation, or tokenization; protect cardholder data with strong cryptography during transmission over open, public networks.
Protect all systems and networks from malicious software; develop and maintain secure systems and software, including secure coding and change control.
Restrict access to system components and cardholder data by business need-to-know; identify users and authenticate access (MFA into the CDE); restrict physical access to cardholder data.
Log and monitor all access to system components and cardholder data; test security of systems and networks regularly, including vulnerability scanning and segmentation penetration testing.
Support information security with organizational policies and programs — risk assessment, incident response, awareness training, and vendor management.
Want the version-4.0-specific detail? See what changed in PCI DSS v4.0 vs. v3.2.1.
How CORE and SENTRY Operationalize PCI-DSS
PCI-DSS is unusual among frameworks in how heavily it weights infrastructure hardening and continuous log review. Two Armorstack portfolios carry most of the operational load.
CORE: Infrastructure Hardening and Segmentation
CORE managed IT services builds and maintains the network segmentation that isolates the cardholder data environment (CDE) from the rest of the network — the single most effective lever for shrinking PCI scope. That includes firewall and network security control configuration, secure baseline builds that remove vendor-default credentials, patch management, and encryption of stored and transmitted account data.
See how segmentation reduces assessment scope in our network segmentation guide.
SENTRY: Continuous Log Monitoring
Requirement 10 calls for logging and monitoring all access to system components and cardholder data, with daily log review. SENTRY’s managed detection and response collects and retains those logs, runs behavioral analytics to surface anomalies, and documents every alert in a format that maps directly to Requirement 10 evidence — turning a daily manual chore into a managed operational function.
VERITY completes the picture with the gap assessment, SAQ or ROC preparation, and policy documentation that Requirement 12 requires.
PCI-DSS Guides
What’s actually new in v4.0 versus v3.2.1 — MFA scope, targeted risk analysis, and the future-dated requirements.
A, A-EP, B, B-IP, C, C-VT, D, and P2PE — which questionnaire fits your merchant scenario.
Transaction-volume thresholds and what validation each level requires — SAQ vs. QSA-led ROC.
Why segmentation reduces scope, common architectures, and how to validate it actually works.
Realistic cost drivers by merchant level, scope, and remediation need — and why one number won’t fit every business.