Key points
• Do not start with the whole site. Start with one payment scenario.
• A useful pilot shows baseline state, deviations, owners, and next steps.
• The best pilot outcome is not a dashboard; it is a team decision to move toward production rollout.
Step 1. Choose a narrow pilot scope
Usually 1-2 payment pages or one high-value checkout scenario is enough. That scope lets the team quickly see executable scripts, third-party dependencies, and browser-side changes.
Step 2. Capture the baseline
A pilot needs four simple layers: controlled pages, script inventory, a header and DOM baseline, and the current third-party dependencies that affect the payment page.
Step 3. Define deviations and triage
A pilot without triage is not convincing. Define which changes are expected, who approves them, and who receives the signal when a payment page changes unexpectedly.
Step 4. Deliver decisions, not just a report
At the end of the pilot, the customer needs a package: what was found, which blind spots were closed, which scripts need owners, which PCI DSS requirements are supported, and what is required for production rollout.
What makes the pilot persuasive
The strongest pilot result combines three things: a real risk found, a clear evidence package, and a short roadmap of 3-5 steps toward production launch.
Acceptance criteria for a 2-3 week pilot
A useful pilot ends with a decision rather than a dashboard demonstration. Before kickoff, agree which checkout states will be exercised, expected inventory coverage, the two test changes, event owners, and the required export.
- Agreed states for one payment journey are covered.
- Scripts are classified and gaps have owners and dates.
- The baseline is approved and linked to a release.
- Expected and test deviations complete the triage path.
- An independent reviewer can reproduce the final sample.
- JSIR implementation guide: How to implement Cartelta JSIR for PCI DSS 6.4.3 and 11.6.1
Stop conditions and the purchase decision
Define failure conditions before kickoff: sensitive data cannot be reliably excluded, a key page state is not observed, a dynamic loader remains opaque, an event cannot be routed, or the export cannot be independently verified. Discovering one of these conditions before a broad contract is a useful pilot outcome.
The go-forward decision should answer four questions: which risk is reduced, which gaps remain, how much operating work stays with the customer, and which next scope will produce a measurable result. Only then should the team evaluate scale and commercial terms.