PCI DSS Technical Architecture Guide

Evidence boundary: TeaQL is not documented here as PCI-listed validated payment software, a PCI DSS certificate, or a substitute for assessment. PCI DSS applicability and validation are determined through the relevant payment brand, acquirer/compliance-accepting entity, and qualified assessment process.

Official starting points:

• PCI Security Standards Council: who follows and enforces PCI standards
• PCI SSC FAQ: no single product provides PCI DSS compliance
• PCI SSC FAQ: card verification values must not be stored after authorization

Payment-Data Boundary

Inventory every component that stores, processes, or transmits payment account data before deciding where TeaQL participates. Prefer tokens or references from a reviewed payment provider over raw account data when the business flow allows it.

Sensitive authentication data such as card verification values must not be stored after authorization, even if encrypted. Do not rely on a model keyword, generated field type, or masking rule to enforce that prohibition.

Control Map

Control concern	TeaQL mechanism that can help	Required system responsibility
Minimise account-data scope	Separate model/service boundaries and explicit selections.	Map all data flows and systems; avoid collection/storage when unnecessary; validate assessment scope.
Access control	Authenticated UserContext plus application request policy.	Implement least privilege, strong authentication, authorization, administrative controls, and periodic review.
Business intent	Query comment/purpose and mutation audit descriptions.	Intent metadata is not permission; test denial and bypass paths.
Audit evidence	Runtime audit hooks, actor/context metadata, masking configuration.	Cover all access paths; protect logs; verify time, identity, success/failure, retention, monitoring, and review.
Data masking	_audit_mask_fields for generated audit metadata.	Tokenize or render account data unreadable as required; test responses, logs, errors, exports, events, and support tools.
Encryption	Provider/driver and platform configuration outside generated queries.	Configure and verify approved cryptography, keys, TLS, certificates, rotation, and plaintext rejection.
Segmentation	Separate models, services, providers, and deployment boundaries.	Prove segmentation effectiveness and prevent uncontrolled joins, exports, credentials, or network paths.
Secure software lifecycle	Model/generation review and reproducible dependency evidence.	Apply the applicable PCI DSS and/or Secure Software requirements, vulnerability management, change control, and assessment.

Authorized Query Shape

Use an application-owned helper that already applies role, tenant, payment-data scope, and the minimum generated selection:

authorizedMaskedPaymentView(ctx)
    .comment("Query masked payment identifiers")
    .purpose("Render the approved payment support view")
    .executeForList(ctx);

The helper is illustrative and application-defined. It must return the exact generated request for the pinned model. Its name does not prove masking, tokenization, authorization, or PCI scope reduction.

Prohibited and Restricted Data

Model and application review should distinguish:

• sensitive authentication data that must not be retained after authorization;
• primary account numbers and other cardholder data requiring applicable rendering, storage, display, transmission, and retention controls;
• payment tokens or provider references with their own threat and scope review;
• ordinary business data that can still become sensitive when joined or exported with payment records.

TeaQL does not currently provide maintained evidence that it automatically disallows CVV/track fields, enforces encryption, masks every sink, or blocks plaintext provider connections.

Audit and Monitoring Test

For an authorized and denied access, verify:

1. authenticated user/service identity and role;
2. business operation and purpose;
3. affected data category without prohibited raw values;
4. success/failure result and timestamp;
5. protected delivery to the intended audit sink;
6. monitoring, retention, access review, and incident workflow;
7. coverage of queries, mutations, exports, errors, support tools, direct database paths, and external integrations.

An auditAs / audit_as call alone is insufficient evidence.

Deployment and Provider Checks

• Pin the generator, runtime, provider, driver, database, and TLS versions.
• Reject plaintext connections and verify certificate/hostname handling.
• Keep payment credentials outside models, generated source, and logs.
• Test database privileges, schema changes, backups, replicas, exports, and administrative access.
• Document responsibility for every shared service and third party.
• Retain the official assessment and reporting evidence required by the compliance-accepting entity; an application-generated certificate is not a substitute.

Review Checklist

• Account-data flows and assessment scope are documented.
• Prohibited post-authorization data is not retained in any format or sink.
• Raw account data is avoided where tokens/references satisfy the use case.
• Authorization and least privilege are tested independently of query intent.
• Audit, masking, encryption, TLS, keys, retention, monitoring, and incident controls are verified.
• Custom SQL, exports, logs, errors, support tools, backups, and external tools are included.
• The relevant assessor/compliance-accepting entity validates the complete environment.

This guide is an engineering aid and does not replace the current PCI standards, payment-brand/acquirer direction, a qualified assessor, or formal validation documentation.