---
tool_id: WACK-TOOL-0092
concept_id: WACK-CONCEPT-0008
playbook_content_id: WACK-CONTENT-0172
status: draft
technical_review: pending
artifact_type: working_worksheet
---

# Common Service Baseline and Customer Overlay

> Separate the BPO controls that are genuinely common from the customer-specific consumption, responsibility, evidence, and residual testing that must still be bound.

**Expected output:** One versioned common-service baseline joined to two customer overlays, shared evidence references, material variants, residual tests, limitations, and change-propagation rules.  
**Working time:** 90 minutes  
**Derived from:** WACK-CONTENT-0172

## Working context

Organization / environment: __________________________________________  
Facilitator / owner: __________________________________________________  
Participants: _________________________________________________________  
Date: ____________________  Review trigger or next date: ______________

## 01 / Find — Define the service that is actually common

Name the legal entity, service and version, business process, features, facilities, remote-work models, workforce, technologies, nested providers, operating period, and intended boundary. Recover the current AOC, responsibility information, service catalog, architecture, inventories, control populations, exceptions, and customer configurations.

- [ ] **Which fact proves the service is shared?**

  Notes: ________________________________________________

- [ ] **Which marketing label is hiding a material implementation variant?**

  Notes: ________________________________________________

## 02 / Map — Build baseline and overlay as separate layers

Record shared control instances, populations, evidence sources, tests, and exceptions in the common baseline. For each customer, map contracted services, enabled features, data and influence paths, integrations, identities, customer actions, provider actions, variants, periods, exclusions, and residual tests.

- [ ] **What does this customer consume differently?**

  Notes: ________________________________________________

- [ ] **Which relationship exists only for one customer?**

  Notes: ________________________________________________

## 03 / Explain — Bind reuse to a bounded claim

For every reused fact, state the exact customer claim it supports, population and period represented, material variants, AOC match, responsibility verbs, limitations, and non-claims. Keep provider, customer, assessor, and accepting-entity authority distinct.

- [ ] **Where does the common evidence stop?**

  Notes: ________________________________________________

- [ ] **What customer fact must be independently established?**

  Notes: ________________________________________________

## 04 / Reduce — Reference, do not clone

Assign stable service-component, control-instance, population, evidence, test, claim, and overlay identifiers. Reference shared objects from customer overlays. Preserve deviations and exceptions as first-class records instead of duplicating or silently overriding the baseline.

- [ ] **Which copied artifact can become one authoritative reference?**

  Notes: ________________________________________________

- [ ] **Which apparent duplicate is actually a customer-specific variant?**

  Notes: ________________________________________________

## 05 / Prove — Run the two-customer and changed-control test

Give the baseline and two different customer overlays to a cold reviewer. Require reconstruction of both service paths and conclusions. Change one common control fact and verify that every affected customer claim, evidence request, test, and report use reopens.

- [ ] **Which conclusion was stretched beyond the baseline?**

  Notes: ________________________________________________

- [ ] **Did the changed fact reach every dependent customer overlay?**

  Notes: ________________________________________________

## Completion check

- [ ] The common service has a stable identifier, version, legal entity, owner, boundary, and period.
- [ ] Shared people, processes, technologies, facilities, remote-work populations, and nested providers are explicit.
- [ ] Material variants and the reason they are or are not pooled are explicit.
- [ ] Each customer overlay records exact services, features, configurations, integrations, identities, data paths, influence paths, and exceptions.
- [ ] Responsibility is allocated through named verbs and evidence outputs rather than whole-requirement labels alone.
- [ ] AOC scope, services, locations, requirements, period, exclusions, and TPSPs are reconciled to actual consumption.
- [ ] Common assessment period, customer assessment period, evidence periods, activation date, changes, failures, and gaps are visible.
- [ ] Shared evidence and tests are referenced through stable identifiers rather than copied into apparently independent records.
- [ ] Customer-specific residual tests and limitations remain explicit.
- [ ] A change to the baseline can identify every affected customer claim and overlay.
- [ ] The record does not treat common-service assessment as official PCI SSC terminology or an automatic customer compliance conclusion.
- [ ] A cold reviewer can reconstruct two different customer conclusions without oral rescue.

## Decision and next action

Decision: _____________________________________________________________  
Owner: __________________________  Due date: ___________________________  
Evidence or artifact location: ________________________________________

---

_Working practitioner worksheet pending technical review. It does not determine PCI DSS compliance, replace the standard, or replace instructions from an assessor or compliance-accepting entity. The Cluster of Wack is an independent resource and is not affiliated with or endorsed by PCI SSC._