Key points
• Start with scope, owners, and acceptance criteria rather than installing across the entire domain.
• The first outcome is an approved inventory and baseline for a real payment journey.
• Expected and unexplained test changes validate detection, routing, triage, and evidence.
• JSIR supports technical controls, while scope, authorization, response, and the PCI conclusion remain with the organization and assessor.
Before integration: define the pilot outcome
Choose one priority payment journey and name its owner. Document URLs and states, the payment-provider integration, locales, tag manager, consent modes, third-party resources, and systems that can alter the page.
Agree acceptance criteria: inventory coverage for the observed states, assigned owners, an approved baseline, detection of a test change, delivery to the responsible role, a documented decision, and a reproducible export.
Phase 1. Build the observed inventory
Enable observation only for the agreed journey and exercise its meaningful states. JSIR is publicly described as observing DOM scripts and third-party sources on the client-side page. Reconcile that output with the repository, tag manager, vendors, and application owners.
For each entry, record purpose, technical and business owner, authorization, integrity method, review date, and decision reference. An unknown script is a classification task, not automatic proof of an attack.
- Implementation guide: Payment page script inventory
- Working checklist: PCI DSS implementation checklist
Phase 2. Approve the page baseline
The baseline should describe an expected page state rather than one accidental snapshot. Record the checkout variant, scripts and origins, meaningful structural signals, selected HTTP headers, version, release, owner, and approval.
Document acceptable variation for consent, locale, A/B tests, rotating identifiers, CDN behavior, and provider responses. Normalization should remove noise without hiding new script origins, changed executable resources, form behavior, or request destinations.
Phase 3. Test an expected and an unexplained change
First deploy a pre-approved change and verify that the event links to the correct baseline, release, and owner. The decision should update the baseline through a controlled process and preserve the previous version.
Then use a safe test deviation that cannot touch real payment data. Validate detection, context, notification, assignment, triage, action, and closure. Agree the test and removal method before execution.
Phase 4. Connect the operating process
Define who receives notifications, who evaluates business context, who may approve a baseline, and who escalates an event as an incident. Email, webhook, or SOC/SIEM routing only helps when the recipient, severity, and response expectation are explicit.
Retain runbooks for an expected release, an unknown third-party script, a header change, and suspicious form behavior. For each scenario, specify the minimum context and required closure evidence.
What belongs in the pilot package
The package should let an independent reviewer reconstruct scope, the expected state, and both test events without oral explanation. Screenshots can help navigation but should not be the only source record.
- Payment-journey map, observation boundary, and responsible roles.
- Inventory with authorization, justification, integrity method, and review status.
- Baseline version, approval, and release relationship.
- Diff, time, page, and context for the expected and test deviations.
- Routing, decision, action, closure, and history export.
- Artifact map: PCI DSS audit evidence map
Production readiness criteria
Move forward when relevant states are covered, unknown scripts are classified, the baseline is approved, test changes are detected, owners actually handle events, and evidence is reproducible. Every remaining gap needs an owner, due date, and accepted risk decision.
Expand one journey type at a time and repeat the validation. Do not copy baseline and normalization rules to a different checkout without testing; architecture differences can hide meaningful changes.
- Related guide: How to run a client-side security pilot without a heavy project
- Methodology: JSIR monitoring methodology
The technical contract for a JSIR pilot
Before enabling observation, agree more than a URL. Define payment-journey states such as initial form display, payment-method selection, 3DS transition, error, and success. For each state, identify expected scripts and resources, permitted variation, the baseline owner, and release linkage.
Document data boundaries separately. Evaluating client-side changes does not require storing PAN, CVC, form values, cookies, or authorization headers. The test protocol should verify those exclusions and describe the structural signals retained instead.
Illustrative pilot profile, not an API schema
{
"journey_id": "checkout-main",
"states": ["payment", "3ds-transition", "success", "error"],
"excluded_data": [
"payment-field values",
"cookies",
"authorization headers"
],
"approved_release": "release-2026.07.15",
"test_events": [
"approved script update",
"safe unknown source"
],
"acceptance_owner": "payment-security-owner"
}What separates an operating control from a demo
An operating result can be repeated after the next release: a new script receives an owner and decision, a page change links to a baseline version, and the event reaches the responsible team and closes with evidence. If the outcome depends on a guided dashboard demonstration, the control is not yet part of the operating process.
- Agreed states are covered by actual observations.
- Exclusion rules pass negative tests and do not hide new sources.
- An expected change and a safe deviation complete the full workflow.
- The export is understandable to someone outside the setup team.
- Pilot plan: How to run a client-side security pilot without a heavy project
Practical steps
1
Agree one payment journey, owners, and acceptance criteria.
2
Enable observation and validate sensitive-data exclusions.
3
Build and authorize the script inventory, then approve the baseline.
4
Run expected and safe test deviations through the complete triage path.
5
Review the evidence package and decide the production scope.
Questions on this topic
Does JSIR replace a PCI DSS assessment?
No. JSIR supports observation, event, and evidence workflows. The organization and its assessor determine scope, control design, operating effectiveness, and the final compliance result.
Does a pilot require rewriting checkout?
The goal is a limited integration with one payment journey. The exact integration method, sensitive-data exclusions, and production impact must be validated in a technical review before rollout.
Which two tests make a pilot useful?
Run one approved release change and one safe unexplained deviation. Both should produce a reproducible path from observation and baseline to owner, decision, action, and retained evidence.