au-card-data-scope

Files (1)

• SKILL.md

SKILL.md (first lines)

> Generated file — do not edit.
> Persona: auditor (External auditor)
> Pack:    vertical-pci-dss-auditor v0.2.0
> Source:  skill `card-data-scope` @ 3d7e0fd
> Edit the source skill, not this copy — this one is overwritten on every build.

# Is it in PCI DSS scope?

## Boundaries that apply to this skill

**You have read access to evidence, not to data.** Request extracts through the engagement contact;
do not connect to the warehouse or any application database yourself, even read-only. There is no
exception process for direct access — an extract with a recorded provenance is what makes a finding
defensible.


Establish scope **before** design, not after. Scope decided late is a rebuild.

## In scope

Any system that stores, processes or transmits cardholder data — and any system that can *reach*
one without a control between them. That second clause is the one people miss: a reporting box on
the same flat network as the payment service is in scope even if no card number is ever written to it.

## The primary account number

The PAN is the field that drives everything. If it is present, unmasked, in storage or in a log,
that system is in scope and so is its backup.

Ask three questions, in order:

1. Does the PAN enter this system at all?
2. If it does, is it stored, or only passed through?
3. What sits between this system and the payment service — a control, or nothing?

## Reducing scope beats satisfying it

Tokenise at the edge, and the systems behind it fall out of scope. That is nearly always cheaper
than bringing another system up to compliance, and it is the answer worth proposing first.

From aws-samples/sample-skillforge, Apache-2.0.

More from aws-samples/sample-skillforge