Solutions
Audit evidence for PCI DSS payment page controls
Build a traceable package that shows what the control is designed to do, who owns it, how it operated during the review period, and how exceptions and changes were resolved.
For PCI program owners, control operators, internal audit, and QSA-facing teams preparing evidence for requirements 6.4.3 and 11.6.1.
A complete sample should connect
The scoped payment journey and approved control design.
Observed scripts, owners, authorization, justification, and integrity method.
Baseline, detected change, alert, triage decision, response, and closure.
Review period, retention, reviewer, and reproducible export or source record.
Updated: July 26, 2026
Review basis
Reviewed against PCI DSS v4.0.1, PCI SSC payment-page guidance, and PCI SSC sampling guidance. Artifact examples support preparation; the assessor defines the final sample and sufficiency.
Design evidence
Procedures, scope, RACI, baseline rules, approval model, and retention requirements.
Operating evidence
Inventory snapshots, observed changes, alerts, reviews, decisions, and periodic control checks.
Traceable sampling
A reviewer can move from requirement to control, event, owner, action, and retained source record.
Separate design from operating effectiveness
A procedure or product screenshot can explain how a control is intended to work, but it does not demonstrate that the control operated throughout the assessment period. Conversely, a raw event export without scope, approval rules, and responsible roles is difficult to interpret.
Prepare both layers: design evidence describing the control and operating evidence showing representative execution, exceptions, review, and follow-up.
Create one chain from observation to decision
For script governance, connect each observed item to its owner, authorization, business justification, integrity method, and latest review. For page changes, connect the comparison to the baseline version, alert, responsible reviewer, release or incident context, decision, action, and closure.
Stable identifiers for pages, scripts, baseline versions, and events reduce manual reconciliation and make samples reproducible across exported reports and source systems.
Build a sample set that shows normal and adverse operation
A useful package does not contain only clean month-end screenshots. Include a normal inventory review, an approved release that changed the observed state, an unexplained deviation or controlled negative test, a closed exception, and evidence that the monitoring mechanism ran at the required or risk-defined frequency.
For each sample, state why it was selected and what population it represents. Sampling is an assessor decision: do not imply that a small convenient selection proves the whole period or every payment journey.
Preserve provenance and export context
Every exported file should identify its source system, generation time, scope filters, period, record count, schema or report version, and the stable identifiers needed to find the authoritative records. If files are transformed, record the transformation and preserve the source.
Checksums or signed packages can help demonstrate that a review bundle did not change after generation, but they do not prove that the underlying control was complete or effective. Access history, approval authority, and exception handling remain part of the evidence story.
Define retention and access before the audit
Agree how long evidence is retained, where authoritative records live, who can alter approvals or close events, and how access changes are logged. Retention should reflect the assessment period and the organization's policy rather than a generic marketing promise.
Run a sample retrieval before the formal review: select a page, script, date range, and change event, then verify that an independent reviewer can reconstruct the decision without oral context.
Run a dry review with someone outside the control team
Give an internal reviewer the requirement mapping and evidence index, but do not provide an oral walkthrough. Ask them to find the source inventory entry, baseline, event, owner decision, action, and closure for one selected journey and date.
Record every question they cannot answer from the package. Missing context, inconsistent time zones, broken references, unexplained record-count differences, and inaccessible source systems are evidence defects to resolve before the formal assessment.
On this page
Pass a 15-minute evidence reconstruction test
Select one payment journey and one material change. An independent reviewer should be able to reconstruct what was expected, what was observed, who decided, what happened next, and where the authoritative records live.
Definition of done
A dated evidence index and manifest whose references resolve to source records, with scope, period, owner, reviewer status, exceptions, retention, and export provenance clearly stated.
01
Choose the population and sample
State the journeys, period, systems, event population, and rationale for the selected normal, changed, and exception records.
02
Link design to operation
Map the requirement and procedure to the inventory snapshot, baseline, event, decision, response, and periodic review records.
03
Capture export provenance
Record source system, query or filters, generation time, schema or report version, record count, and source identifiers.
04
Verify access and immutability controls
Confirm who can approve scripts, change baselines, close events, generate exports, and alter the authoritative history.
05
Reconstruct without oral context
Have someone outside the operating team follow the references and log missing, inconsistent, or inaccessible evidence.
Example evidence manifest
The manifest describes the exported package and points back to authoritative records; it is not itself proof that the control operated.
{
"manifest_version": "1.0",
"generated_at": "2026-07-26T09:00:00Z",
"scope": {
"journey": "checkout-card-entry",
"period": ["2026-07-01", "2026-07-26"]
},
"source": {
"system": "payment-page-control-system",
"report_version": "inventory-and-events-v3",
"record_count": 18
},
"records": {
"inventory_snapshot": "INV-SNAPSHOT-2026-07-26",
"baseline": "BASE-2026-07-20.2",
"change_event": "EVT-1161-0042",
"owner_decision": "DEC-0042",
"closure": "CLOSE-0042"
},
"review": {
"reviewer": "internal-audit",
"status": "pending"
}
}PCI DSS payment-page evidence index
CSV fields for requirement, objective, journey, owner, source system, period, source record, reviewer, exception, retention, and access class.
CSV · UTF-8 · includes one clearly marked example row
Agree the assessment period, population, sample, retention, and acceptable source systems with the assessor. Do not replace authoritative records with screenshots or manually edited extracts.
Evidence assembly workflow
Build the package continuously instead of reconstructing it shortly before the assessment.
01
Map
Map requirements to controls, owners, systems, and expected artifacts.
02
Collect
Capture inventory, baselines, events, decisions, and periodic reviews.
03
Correlate
Link observed items to approvals, releases, incidents, and responsible roles.
04
Review
Check completeness, exceptions, access, timestamps, and reviewer sign-off.
05
Export
Produce a scoped, dated package while preserving the authoritative source record.
Artifact map for 6.4.3 and 11.6.1
The exact sample and period must be agreed with the assessor.
| # | Control objective | Design artifact | Operating artifact | Reviewer question |
|---|---|---|---|---|
| 01 | Script inventory | Inventory schema and scope procedure | Dated export of observed scripts | Does the register match the live page? |
| 02 | Authorization and justification | Approval workflow and role model | Approved records and sampled exceptions | Who approved each script and why? |
| 03 | Integrity or authenticity | Selected methods and exception criteria | Checks, signatures, hashes, or monitoring results | How is substitution or unauthorized change addressed? |
| 04 | Page baseline | Baseline approval and update procedure | Versioned baseline with owner and release | What state was expected on this date? |
| 05 | Change detection | Comparison scope and notification rules | Event, diff, timestamp, affected journey | Was the change detected with useful context? |
| 06 | Response | Triage and escalation procedure | Owner decision, action, and closure | Was the event handled by an authorized role? |
| 07 | Retention | Retention and access policy | Retrievable sample and access history | Can the review period be reproduced? |
| 08 | Export provenance | Source, schema, filter, and generation procedure | Manifest, record count, source IDs, generation time | Can each exported item be traced to its source? |
| 09 | Exceptions and failures | Exception and control-failure procedure | Open/closed exceptions, owner, remediation, retest | Are gaps visible rather than omitted from the sample? |
Avoid screenshots as the only source of truth. Keep exports and source records machine-readable where practical and preserve their scope and generation time.
Evidence supports assessment; it does not make the conclusion
Cartelta can organize inventory, comparison, event, and export data. The organization and its assessor determine applicability, sampling, sufficiency, operating effectiveness, and the final PCI DSS result.
Audit evidence questions
Usually not by itself. A useful sample includes scope, time, source record, owner, control context, and any related decision or response. The assessor decides sufficiency for the specific assessment.
Keep the authoritative history according to policy, but prepare a scoped sample and exception summary for review. The sample should show normal operation as well as meaningful deviations and their resolution.
Subject to the assessor's sampling method, useful candidates include normal control operation, an approved release, an unexplained deviation or controlled test, an exception, a failed or missed run and its resolution, and a periodic owner review.
No. A checksum can support package integrity after generation, but sufficiency still depends on scope, population, provenance, authoritative source records, owners, decisions, operating period, and assessor testing.
Build the underlying controls
Implementation checklist
Track scope, controls, owners, evidence, retention, and RACI in one place.
OpenHow to build an evidence pack
Use a practical article focused on review preparation and sample quality.
OpenJSIR monitoring methodology
Understand observation, baseline, limitations, and the path from change to evidence.
OpenTest whether one sample is independently reviewable
A focused evidence review exposes missing owners, timestamps, approvals, and response records before the formal assessment.
Discuss an evidence review