Data Classification Policy

1. Purpose

This policy classifies the types of data handled by the Gatelithix Gateway, defines handling rules for each category, and establishes storage, transmission, retention, and disposal requirements. It ensures that cardholder data is protected according to its sensitivity, in compliance with PCI DSS 4.0.1 Requirements 3 and 4.

2. Scope

This policy applies to all data stored, processed, or transmitted by Gatelithix Gateway systems, including:

• Cardholder data received from merchants via the API
• Data stored in Cloud SQL databases (PCI and Core)
• Data stored in Cloud KMS (encrypted key material)
• Data in transit between services, processors, and clients
• Data in logs, error messages, and monitoring systems
• Data in backups and database snapshots
• Data used in development and testing environments

3. Roles and Responsibilities

4. Data Classification Levels

4.1 Classification Definitions

4.2 PCI Data Categories

L1: Prohibited — Sensitive Authentication Data (SAD)

Sensitive Authentication Data must never be stored after authorization, even if encrypted (PCI DSS 3.3.1).

Gatelithix implementation: The vault service accepts CVV in the tokenization request, includes it in the processor API call, and discards it from memory. CVV is never written to any database, log, cache, or persistent storage.

L2: Restricted — Cardholder Data (CHD)

PAN masking rules:

• Display: show BIN (first 6 digits) and last 4 digits only (e.g., 424242******4242)
• API responses: return bin and last4 fields; never return full PAN
• Logs: never log any portion of PAN beyond BIN and last 4
• Database (non-vault): store only bin (string) and last4 (string) — never the full PAN

L3: Confidential — Business-Sensitive Data

L4: Internal — Operational Data

L5: Public — Public Information

5. Handling Rules by Classification

5.1 Storage Requirements

5.2 Transmission Requirements

5.3 Logging Restrictions

6. Development and Testing

6.1 Test Data Requirements

1. Production cardholder data shall never be used in development, testing, or staging environments.
2. All development and testing shall use designated test card numbers:

3. Test CVV: any 3-digit number (e.g., 123). Test expiry: any future date (e.g., 12/29).
4. Sandbox processor credentials (prefixed sk_test_*) shall be used for all non-production environments.
5. The vault encrypts test PANs with the same encryption pipeline as production — security controls are not bypassed in test mode.

6.2 Code Review Data Checks

Every code review shall verify:

• No PAN, CVV, or SAD appears in source code, comments, or test fixtures (except designated test PANs above)
• No PAN is logged, included in error messages, or returned in API responses
• Structured logging is used (not string concatenation that could leak sensitive fields)
• json.Marshal is used for audit metadata serialization (not fmt.Sprintf)

7. Data Retention and Disposal

7.1 Retention Schedule

7.2 Data Disposal

1. When PAN data is no longer needed (token revoked, merchant offboarded), the encrypted PAN record shall be securely deleted from the vault database. This deletion is automated by the cmd/vault-purge Cloud Run job (Phase 110), which runs daily at 05:00 UTC and HARD-DELETEs vaulted_cards rows that have crossed any of three retention boundaries: soft-delete grace (7 days after deleted_at), post-revocation retention (90 days after revoked_at), or merchant offboarding (90 days after merchant_offboarded_at). The PCI Cloud SQL FK cascade atomically drops dependent gateway_tokens and processor_tokens rows.
2. Secure deletion means: DELETE from Cloud SQL (which overwrites on SSD via GCP’s storage layer) plus the associated Cloud KMS key version may be scheduled for destruction per the Key Management Policy. True crypto-shred (KMS key-version destruction once no rows reference a given version) is deferred to v2.5+; Phase 110 ships only the row-level disposal half.
3. Cloud SQL backups containing deleted PAN data expire per the retention schedule above. No manual extraction of individual records from backups is performed.
4. When decommissioning a CDE system component, all data shall be securely deleted and the deletion documented.
5. Paper documents containing cardholder data (if any) shall be cross-cut shredded. In practice, Gatelithix operates paperlessly — no CHD exists on paper.

Operational procedure for the automated purge job — including the first-week DRY-RUN rollout, manual trigger commands, and integration with the daily Req 10.4 log review — is documented in compliance/runbooks/vault-purge.md.

7.3 Automated Retention Enforcement

1. A scheduled job shall review and purge expired data per the retention schedule.
2. The purge job logs which records were deleted (by token reference, never by PAN) in the audit trail.
3. The ISO reviews retention compliance quarterly.

8. Acceptable Use

1. Cardholder data shall be accessed only for legitimate business purposes: payment processing, refund processing, dispute resolution, or security investigation.
2. Cardholder data shall not be:
   • Copied to personal devices, USB drives, or personal cloud storage
   • Sent via email, chat, or any unencrypted communication channel
   • Used for purposes other than those listed above
   • Shared with unauthorized personnel or third parties
3. Personnel who encounter cardholder data outside the vault (e.g., in a log file, error message, or database query result) shall immediately report it to the ISO for remediation.

9. Compliance and Enforcement

1. Violations of this policy, particularly unauthorized storage or exposure of PAN or SAD, shall be treated as security incidents per the Incident Response Plan.
2. Unauthorized PAN found outside the vault triggers the PCI DSS 12.10.7 response procedure: isolate the system, securely delete the data, investigate how it arrived there, and remediate the root cause.
3. Intentional mishandling of cardholder data is grounds for immediate termination and potential legal action.

10. Related Documents

• Information Security Policy (POL-001) — Parent policy
• Key Management Policy (POL-004) — Encryption key lifecycle for PAN protection
• Access Control Policy (POL-002) — Who can access what data
• Incident Response Plan (POL-005) — Response to data exposure incidents
• Change Management Policy (POL-006) — Test data requirements for changes
• PCI DSS 4.0.1 Requirements 3 and 4

11. Document History