Controls and evidence for the cardholder data environment
PCI DSS v4.0 expects need-to-know access that is reviewed, MFA into the cardholder data environment, logs that are reviewed with automated help, and testing on a fixed rhythm. Ciyora runs those controls for banks, credit unions, fintechs and merchants, and keeps the records your QSA will sample.
About the standard
The Payment Card Industry Data Security Standard is maintained by the PCI Security Standards Council. Version 4.0 (with its 4.0.1 revision) organises twelve principal requirements under six goals, and applies to every entity that stores, processes or transmits cardholder data, and to the system components connected to the cardholder data environment. Requirements that were future-dated in v4.0, such as reviewing all user accounts every six months and automated log reviews, have been in force since March 31, 2025.
For financial services, PCI DSS sits next to other expectations such as the FFIEC IT Examination Handbook and the GLBA Safeguards Rule, which ask for many of the same controls: least-privilege access, MFA, monitoring and incident response. The table below follows the PCI DSS requirement numbers.
How Ciyora maps to the requirement areas
Each row names a control area, what Ciyora does for it, and the evidence it can produce. Your own policies, people and processes still matter: the platform helps you operate and evidence the controls.
| Requirement area | How Ciyora helps | Evidence you can produce | Modules |
|---|---|---|---|
| Req. 1 Network security controls | Deny-by-default access into the cardholder data environment by identity, group, device tag, host and port; cloud checks for security groups that allow unrestricted inbound traffic. | Versioned access policy with diff and history; posture findings mapped to PCI DSS. | VPN, Armor |
| Req. 2 Secure configurations | Cloud configuration checks against CIS benchmarks with remediation steps, drift and exceptions; infrastructure-as-code scanning. | Posture score history, findings workflow and control pass rates for PCI DSS. | Armor |
| Req. 5 Protecting systems from malicious software | Endpoint detection with signature and indicator matching, memory scanning and response actions through the Ciyora endpoint agent. | Endpoint detections, agent coverage and response history. | Detect |
| Req. 6.3 Identifying and addressing vulnerabilities | Vulnerabilities ranked by CVSS, EPSS and the CISA Known Exploited Vulnerabilities catalog, with status workflow and affected assets, so critical patches are tracked against the one-month window. | Vulnerability status over time with remediation dates. | Discover |
| Req. 7 Restricting access by business need to know | Access requests with approval; periodic access reviews of user, third-party and system accounts (7.2.4, 7.2.5.1); separation-of-duties checks; unused grants flagged. | Access review evidence packs with every decision, reviewer, time and comment; SoD reports. | Fortress, Comply |
| Req. 8 Identifying users and authenticating access | Unique identities matched across systems; MFA status per identity; just-in-time privilege that can require MFA; credential vault with rotation; owners and expiry for service accounts and API keys (8.6). | Identities without MFA, rotation history, privileged activation history and non-human identity inventory. | Fortress |
| Req. 10 Logging and monitoring | Central log collection with search and pivots; Sigma detection rules and alerting as an automated mechanism for log review (10.4.1.1); collector pipeline health to notice failed logging; recorded privileged sessions. | Log search and export, alert history, pipeline health and session recordings. | Detect, Fortress |
| Req. 10.3 Protecting audit logs | Administrative actions in Ciyora are written to a per-tenant hash chain, so a changed or deleted entry is detectable; file integrity monitoring on servers. | Audit chain verification and file integrity events. | Comply, Detect |
| Req. 11 Testing security regularly | Internal and credentialed vulnerability scans (11.3.1); external attack-surface discovery; file integrity monitoring as a change-detection mechanism (11.5.2). | Scan history with findings and rescans; file integrity events. | Discover, Detect |
| Req. 12.10 Incident response | Incident queue with owner and severity, timelines of signals, notes and response actions; playbooks under your approval. | Incident records with timelines and actions. | Detect |
| Req. 12.5 Scope and inventory | Inventory of endpoints, servers, certificates, cloud resources and SaaS applications with owners, to help confirm what is in scope. | Asset and SaaS inventories. | Discover |
| Data leaving the environment | Endpoint data-protection policies for file transfers, USB devices, printing and AI tools, with employee notices built in. | Data-protection events and violations. | Monitor |
What stays with your QSA and your ASV
Ciyora is not an Approved Scanning Vendor and does not perform the quarterly external scans that requirement 11.3.2 reserves for an ASV, and it does not store or tokenize card data. Your Qualified Security Assessor decides scope and whether a control is in place; Ciyora helps you run the controls between assessments and hand over the records when they are sampled.
Please note. Ciyora is not a certification and does not make an organization compliant on its own. This page describes how Ciyora capabilities map to requirement areas and help you produce evidence. Always read the current text of the regulation or standard and take advice from your compliance team, auditors or legal counsel.
Walk through your control set with us
Bring your latest audit observations or gap assessment, and we will show where Ciyora fits and where it does not.