PCI-DSS Responsibility Matrix & Compliance Summary

Document Reference: AUC-SEC-PCI-001
Version: 2.2.0
Effective Date: October 24, 2026
Last Updated: October 24, 2026
Classification: Public / Customer & Auditor Guidance
Standard Alignment: Payment Card Industry Data Security Standard (PCI-DSS) Version 4.0.1 (Merchant SAQ-A Scoping)

Executive Summary (ISO 24495-1 Plain-Language Overview)

[!IMPORTANT] Legal Precedence Notice: This plain-language summary is provided solely for reader convenience and payment compliance audit navigation pursuant to ISO 24495-1:2023. It reflects internal compliance scoping and technical division of responsibility. In the event of any conflict, governing contractual terms and PCI-DSS standards strictly control.

• Subscription Billing Scoping: Operates under PCI-DSS SAQ-A. Customer payment data is entered directly into hosted client-side iFrames managed by a certified PCI Level 1 provider (Stripe); no raw credit card data touches Auctoric servers.
• AI Platform Scoping: Auctoric is not a certified Cardholder Data Environment (CDE) for processing credit card numbers; submitting unencrypted Primary Account Numbers (PAN) into AI prompts is prohibited by policy.
• Edge Redaction Guardrail: Auctoric provides a real-time defense-in-depth redactor that automatically masks detected credit card numbers ([CARD_REDACTED_XXXX]) before prompt execution.
• 12 Requirements Division: Formal matrix mapping obligations between the Payment Processor, Auctoric, and Customer Deployers under PCI-DSS v4.0.1.

High-Intent Payment Security FAQ (AEO Direct Answers)

What is Auctoric’s PCI-DSS compliance scope and attestation level?

Under Section 1.1 and Section 4, Auctoric is assessed under PCI-DSS v4.0.1 Merchant SAQ-A for subscription billing, delegating all payment capture to certified Level 1 payment processors (e.g., Stripe) using client-side tokenized elements.

Can enterprise customers send raw credit card numbers (PAN) through Auctoric’s AI APIs?

No. Under Section 1.2, submitting unencrypted Primary Account Numbers (PAN) or Cardholder Data (CHD) into AI inference prompts is strictly barred. Customers must tokenize cardholder data prior to prompt ingestion.

How does Auctoric prevent accidental exposure of payment card numbers in AI prompts?

Under Section 1.2 and Section 3, Auctoric deploys an automated Edge PCI/PAN Redaction Guardrail that detects 16-digit card patterns and algorithmic checksums, tokenizing them into synthetic strings before prompts reach underlying models.

1. Executive Summary & Cardholder Data Scoping

Auctoric, LLC (“Auctoric”) maintains administrative and technical security measures to prevent the unauthorized processing, transmission, or exposure of Cardholder Data (CHD) and Sensitive Authentication Data (SAD).

1.1 Auctoric Direct Subscription Billing Scope (Merchant SAQ-A)

For commercial subscription invoicing and platform billing:

• Auctoric utilizes a certified PCI-DSS Level 1 Payment Service Provider (e.g., Stripe) to collect and tokenize payment credentials.
• Payment forms utilize secure client-side iFrames (e.g., Stripe Elements).
• No Primary Account Numbers (PAN), CVV/CVC codes, or magnetic stripe data ever touch, traverse, or reside on Auctoric servers, databases, or container instances.
• Auctoric’s corporate billing environment is designed and managed to comply with PCI-DSS Self-Assessment Questionnaire A (SAQ-A) criteria.

1.2 Customer AI Inference & Prompt Processing Scope

When enterprise customers process data through the Auctoric platform:

• Prohibition on Raw PAN: Customer prompts containing unencrypted Cardholder Data (PAN) are strictly prohibited under our Acceptable Use Policy. Auctoric is not a certified PCI-DSS Service Provider for cardholder processing environments.
• Defense-in-Depth Redactor: Auctoric deploys an automated Edge PCI/PAN Redaction Guardrail designed to detect and mask card number patterns before payloads reach inference models. This redactor functions as a risk-mitigation security guardrail, not as a certified cardholder data transit gateway.
• Zero Model Retention: Prompts are processed in volatile memory enclaves and not retained in model weights, preventing card data persistence.

2. PCI-DSS v4.0.1 Responsibility Matrix

The following matrix delineates the division of responsibilities between Auctoric, Third-Party Payment Processors, and Customer Deployers under PCI-DSS v4.0.1 control criteria:

3. Customer Deployment Architecture Recommendations

To ensure customer applications utilizing Auctoric maintain complete PCI-DSS compliance:

flowchart LR
    CustomerUser["End User Browser"] --> PayGate["PCI-DSS Level 1 Gateway (e.g. Stripe Checkout)"]
    CustomerUser --> ClientApp["Customer Application"]
    ClientApp --> Redact["Auctoric PCI Redaction Guardrail (Defense-in-Depth)"]
    Redact -->|Masked Tokenized Payload| Inference["Auctoric Inference Engine"]
    PayGate -->|Opaque Token Only| ClientApp

1. Never transmit unmasked PAN into inference prompts: Enable the Auctoric PCI Redactor guardrail to replace 16-digit card strings with synthetic tokens ([CARD_REDACTED_XXXX]).
2. Utilize direct hosted tokenization: Always collect cardholder data directly through payment processor SDKs without passing card numbers through customer backend web servers or Auctoric API payloads.

4. Compliance Assessment Summary

• Assessed Entity: Auctoric, LLC
• Assessment Framework: PCI-DSS Version 4.0.1
• Scope Evaluated: Merchant SAQ-A Self-Assessment (Direct Subscription Billing)
• Assessment Mode: Internal Self-Assessment aligned with SAQ-A requirements
• Status: Designed and Managed in Compliance with SAQ-A Criteria

(Note: Auctoric maintains SAQ-A compliance documentation for its commercial subscription billing. Auctoric does not issue a Service Provider Attestation of Compliance (AoC) for customer cardholder processing, as raw cardholder data is prohibited on platform inference endpoints.)