Example: PCI DSS Compliance Playbook

PCI data, or Payment Card Industry data, refers tocredit and debit card information that organizations handle when processing payments. It is strictly governed by the Payment Card Industry Data Security Standard (PCI DSS), a global baseline created by major credit card companies to prevent fraud and secure transactions.

Overall Flow

Start

└─► Is CCN?

├─ No ──► Take No Action ──► Complete

└─ Yes ──► Add Classification: "PCI Regulated Data" (on Database)

└─► PCI Zone?

├─ Yes ──► MIP Label: "Encrypted v11.0" (Add/Replace) ──► Complete

└─ No ──► Shred (permanent deletion) ──► Complete

Decision Point 1: "Is CCN?"

• Logic: Data Types → Contains → Credit Card Number
• Decision Weight: 1

Detects Credit Card Numbers using the built-in AnyFind engine (displayed in italics in the UI, distinguishing it from custom regex types).

• A single CCN match scores the required weight of 1 and routes to Yes.
• No CCN found routes to No.
• Note: Both decision points in this playbook use Decision Weight 1 (not 0 as seen in the PCI playbook). This means the condition must reach a score of at least 1 to fire the Yes branch — with one rule worth 1 point, this is functionally identical to a simple pass/fail, but the explicit scoring makes the intent unambiguous and allows additional weighted rules to be added later.

If No — No CCN found

• Action: Take No Action (Automated)
• Nothing happens. The record is left as-is with no classification or remediation applied.

→ Complete

If Yes — CCN detected

• Action: Add Classification → "PCI Regulated Data" (Automated)
• Critical distinction: The action option reads "Perform Action on Database..." — not "Perform Action on File."

This playbook is designed to run against database targets, classifying database records or rows containing CCNs rather than files.

• The classification type is Add (not Replace), meaning "PCI Regulated Data" is appended to any existing classification already on the record, preserving prior labels.

Decision Point 2: "PCI Zone?"

• Logic: Target Endpoint Tags → Contains → US
• Decision Weight: 1

This decision routes based on where the data was found, not on the data content itself.

• Specifically, it checks whether the target endpoint carrying the Credit Card Numbers (CCN) has been tagged "US" in Spirion Sensitive Data Platform. You can see these endpoints on the Tag Management page in the screenshot below.
  
  
• This tag represents the organisation's designated PCI-compliant infrastructure zone — US-based endpoints that are within scope and authorised to hold cardholder data.

If Yes — CCN is in the PCI Zone (US-tagged endpoint)

• Action: MIP Label → "Encrypted v11.0" / Add/Replace Label (Automated)

A Microsoft Information Protection (MIP) label named "Encrypted v11.0" is applied to the result.

• Label Application is set to Add/Replace, meaning any existing MIP label is overwritten with this one.
• This enforces encryption-level protection on PCI data that legitimately resides within the authorised US PCI zone — the data stays in place but is protected by Microsoft's labelling and encryption enforcement layer.

→ Complete

Key Objects and Design Observations

Notable Design Decisions

1. Database-scoped action — unlike most playbook examples which act on files, this operates on database content. This is appropriate for PCI DSS since CCNs most commonly live in structured databases (payment systems, CRM, ERP).
2. Tag-based zone routing — using Target Endpoint Tags rather than a path string means the PCI Zone designation is managed through endpoint tagging, not hard-coded path values. This scales cleanly — adding or removing an endpoint from the PCI Zone is just a tag change, not a playbook edit.
3. Shred for out-of-zone CCNs — this is an explicit, deliberate policy decision: cardholder data outside the PCI-compliant zone has no business justification and must be eliminated immediately. This directly supports PCI DSS data minimisation requirements.
4. MIP label for in-zone CCNs — rather than quarantine or no-action, in-zone data receives a Microsoft encryption label, ensuring it remains accessible to authorised users while being protected against unauthorised access or sharing. This reflects a mature "protect in place" approach.
5. Fully automated end-to-end — including the Shred action. This requires high confidence in both the AnyFind CCN detection accuracy and the endpoint tagging accuracy before deployment in production, given the irreversibility of shredding.