CinderRook / methodology examination
How the scope map earns its signals.
The wizard is a deterministic briefing tool. It organizes five operating inputs into five visible signals, makes uncertainty impossible to miss, and turns open questions into an ordered assessor conversation.
CinderRook is not a Qualified Security Assessor (QSA).
This page examines the methodology behind the scope wizard; it is not a certified assessment, formal PCI DSS scope determination, or SAQ assignment.
The decision spine
- 01
Inputs
Capture the payment, location, ownership, system, and evidence context.
- 02
Indicators
Assign contained, expanded, or unclear to each independent branch.
- 03
Roll-up
Let any unclear signal take precedence over expanded or contained.
- 04
Recommendations
Sort evidence, boundary, ownership, and edge-case work by priority.
01 · Inputs
Five steps, one operating picture.
The wizard collects the minimum context needed to discuss a payment boundary without pretending the boundary is already proven. Optional notes add context for the briefing; they are not scored and do not change a signal.
Context before conclusion.
Each step describes a different boundary: the flow itself, where it operates, who owns the work, what it touches, and what evidence supports the story.
- 01
Payment flows
Channels and card-data handling
Captures e-commerce, in-person, recurring, and phone/mail channels, plus where card entry appears to happen.
- 02
Locations
Operating regions and data locations
Records single or multiple US locations, international operations, and whether cardholder data sits on-site, in the cloud, or in both.
- 03
Outsourcing
Processing ownership and security tasks
Maps fully or partially outsourced processing, in-house responsibility, and outsourced hosting, monitoring, support, or no known owner.
- 04
Connected systems
System inventory and segmentation
Identifies checkout, POS, ERP/order management, customer support, or no known connected system, then asks how the boundary is segmented.
- 05
Third parties
Provider types and evidence status
Names payment processors, cloud hosts, SaaS platforms, managed service providers, QSAs/assessors, and whether evidence is current.
02 · Indicators
Every branch stays visible.
The report does not jump straight to an SAQ label. It presents five SAQ-style indicators independently so an operator or assessor can see which assumption produced each signal.
| Input branch | Signal | Working assumption |
|---|---|---|
| Provider-hosted | Contained · “SAQ A-style” | Card entry appears to stay with the payment provider, subject to redirect, integration, and fallback details. |
| Tokenized | Contained · “SAQ A-EP-style” | Tokens can reduce direct card-data exposure, but scripts, redirects, APIs, and connected systems remain relevant. |
| Environment handles card data | Expanded · “SAQ D-style” | Storage, processing, or transmission by the environment calls for a broader technical review until those paths are documented. |
| Unclear | Unclear · validation required | The payment-page ownership, tokenization behavior, fallback, or manually keyed path has not been established. |
| Input branch | Signal | Working assumption |
|---|---|---|
| On-site | Contained | The identified cardholder-data footprint is primarily on-site; every device and location still needs confirmation. |
| Cloud | Contained | The identified footprint is primarily cloud-based; hosted services and their integration boundaries still need confirmation. |
| Both on-site and cloud | Expanded | Cardholder-data locations span physical and cloud environments, increasing the inventory and boundary work. |
| Unclear | Unclear | The physical and cloud boundary is not yet clear. Multiple operating regions increase inventory scrutiny but do not independently change this signal. |
| Input branch | Signal | Working assumption |
|---|---|---|
| Fully outsourced | Contained | Payment processing is described as provider-led, while contracts, operating responsibilities, and evidence obligations still need to align. |
| Partially outsourced | Contained | The payment and security boundary is shared across teams and providers; the handoffs must be mapped together. |
| In-house | Expanded | The business retains a significant part of payment responsibility, so internal control ownership is central to the review. |
| Unclear | Unclear | The current answers do not identify who owns core payment work or the associated evidence obligations. |
| Input branch | Signal | Working assumption |
|---|---|---|
| Segmented | Contained | The payment environment is described as segmented from other systems, pending validation that the controls work as designed. |
| Partially segmented | Expanded | Some separation exists, but connected systems may remain in scope until the remaining boundary questions are closed. |
| Not segmented | Expanded | Connected systems may share a broad scope with the payment environment and require network-boundary validation. |
| Unclear | Unclear | The current answers do not establish the boundary around connected systems or whether segmentation is effective. |
| Input branch | Signal | Working assumption |
|---|---|---|
| Current attestation | Contained | The provider evidence set is described as current, with the integration and responsibility matrix still requiring review. |
| Contractual-only | Expanded | Contracts exist, but current provider attestations are not confirmed; commitments are not treated as proof of the live integration. |
| Not collected | Expanded | Provider evidence has not yet been collected, so the external boundary is treated as needing broader review. |
| Unclear | Unclear | The current answers do not establish what evidence is available or how recently it was reviewed. |
03 · Roll-up
Uncertainty wins the tie.
The summary is intentionally conservative. It never lets a reassuring signal erase an unclear boundary, and it keeps a contained result tied to evidence and integration review.
Any unclear indicator takes precedence. The summary says signals need validation before an SAQ path can be confirmed.
One expanded signal yields a focused review; multiple expanded signals yield a broader review.
No expanded signals yields a contained-boundary summary, with provider and integration evidence still important.
The result remains directional planning output, not a formal PCI DSS scope or SAQ determination.
04 · Recommendations
Open loops become a worklist.
The next steps always begin with qualified-assessor review. After that, CinderRook sorts the work into high, medium, and low priority so the team knows what to validate first.
A recommendation is a prompt to gather proof, assign ownership, or validate a boundary—not a finding that compliance has failed.
Card-data flow and location uncertainty
HighDocument where card entry happens, what the merchant receives, storage, transmission, retention, access, deletion, and every fallback or manually keyed path.
Unsegmented or unclear boundaries
HighValidate the network boundary and identify systems that could influence the payment path.
Partial segmentation
MediumClose the remaining boundary questions and preserve evidence that the controls work as designed.
Missing or unclear provider evidence
HighRequest current attestations, responsibility matrices, and supporting contract language from each provider.
Contractual-only provider evidence
MediumPair contractual commitments with current attestations and a documented review cadence.
Unclear or in-house ownership
High / MediumName internal and external owners for payment, hosting, monitoring, support, and evidence tasks. Unclear processing ownership is high priority; in-house ownership is medium.
Operational edge inventory
MediumInventory phone/mail, in-person, international, store, call-center, and other paths that differ from the primary checkout.
05 · Boundaries
Useful because it knows where to stop.
CinderRook is designed to make the assessor conversation sharper, not to turn a directional tool into a certification claim.
CinderRook does
- Organizes inputs into directional signals.
- Exposes uncertainty instead of smoothing it over.
- Highlights evidence and ownership gaps.
- Prepares an assessor briefing and prioritized next conversation.
CinderRook does not
- Assign a final SAQ, certify compliance, or replace a QSA.
- Prove that hosted payment or tokenization removes all scope.
- Treat contracts or attestations as a substitute for validating the actual integration and environment.
- Turn a working assumption into a formal PCI DSS scope determination.
The practical next move
Use the map, then bring the brief to a qualified assessor.
CinderRook can organize the questions. A qualified assessor confirms the applicable path, validation method, and final scope.
CinderRook is not a Qualified Security Assessor (QSA). This page examines the methodology behind the scope wizard; it is not a certified assessment, formal PCI DSS scope determination, or SAQ assignment.