domains / security / pci-dss-evidence-review / pci-compliance

pci-compliance

Skill card

combined

The two copies overlap on PCI DSS scope, data minimization, and tokenization, but they serve different purposes and contain material steps the other lacks. The first copy is an implementation guide with the 12 core requirements, compliance levels, and code examples for sanitization and tokenization. The second copy is an evidence-review procedure for a scoped assessment, emphasizing data-flow mapping, verification of actual integration behavior, and producing a control/evidence/gap table. They also disagree on the use of custom encryption: the first provides a 'Custom Tokenization' code snippet, while the second explicitly warns against building a custom card vault from an illustrative snippet. Crowning one would hide the other's distinct approach to either implementation or assessment evidence.

Repositories

Other copies

Combined skill

# PCI DSS Compliance and Evidence Review

## When to Use
- Implementing PCI DSS compliance for payment systems.
- Reviewing payment data flows for a scoped PCI assessment.
- Preparing engineering control evidence for an assessor.

## Inputs and Prerequisites
- Identify merchant/service-provider role, acquiring institution, and processor integration.
- Obtain current PCI SSC documents and confirm applicability with the assessor or acquirer.
- Clarify goals, constraints, and required inputs for the specific system.

## Procedure

### 1. Map Data Flows and Scope
- Map forms, APIs, storage, queues, logs, telemetry, backups, and support exports.
- Identify all systems handling account data.
- Determine PCI DSS compliance level based on transaction volume:
  - **Level 1**: > 6 million transactions/year (annual ROC required)
  - **Level 2**: 1-6 million transactions/year (annual SAQ)
  - **Level 3**: 20,000-1 million e-commerce transactions/year
  - **Level 4**: < 20,000 e-commerce or < 1 million total transactions

### 2. Implement Core Controls
- **Network Security**: Install and maintain firewall configuration; do not use vendor-supplied defaults.
- **Data Protection**: Protect stored cardholder data; encrypt transmission across public networks.
- **Vulnerability Management**: Protect against malware; develop and maintain secure systems.
- **Access Control**: Restrict access by business need-to-know; identify and authenticate users; restrict physical access.
- **Monitoring**: Track and monitor all access; regularly test security systems.
- **Policy**: Maintain an information security policy.

### 3. Data Minimization and Tokenization
- **Never Store**: Full track data, CVV/CVC, PIN/PIN block.
- **Can Store (if encrypted)**: PAN, cardholder name, expiration date, service code.
- **Tokenization**: Prefer provider-hosted collection (e.g., Stripe.js) to keep raw card data off the server. Verify that the application actually only receives tokens.
- **Custom Encryption**: Do not build a custom card vault from illustrative snippets. If custom storage is unavoidable, use reviewed, qualified encryption utilities and document the risk.

### 4. Logging and Redaction
- Use allowlisted event fields in logs and responses.
- Mask PAN in logs (e.g., first 6 and last 4 digits).
- Remove prohibited fields (CVV, PIN) from logs and error messages.
- Test nested errors and retries with synthetic data to ensure no sensitive data leaks.

### 5. Evidence Collection and Gap Analysis
- Map required controls to implementation evidence (network boundaries, configuration, access, monitoring).
- Verify role and resource authorization together.
- Produce a control/evidence/gap/owner table.
- Keep unverified controls marked as gaps.
- Treat SAQ eligibility and formal attestation as decisions requiring current guidance from the assessor or acquirer.

## Verification
- Data-flow inventory reconciled with actual integration and telemetry.
- Access denial produces no payment or data side effect.
- Redaction checked on nested data and exceptions.
- Evidence tied to actual configuration and test results, with explicit gaps.

## Limitations
- Encryption, hosted checkout, or a passed scan alone does not prove compliance.
- This skill does not certify compliance or determine assessment eligibility on its own.
- Never use live cardholder data as a test fixture.