PCI DSS & DATA SECURITY POLICY

1. Scope & Applicability

This policy governs payment card processing and data security controls for Upmos and applies to all systems, personnel, vendors, and processes that handle, transmit, or could impact cardholder data environment (CDE) security.

2. Roles & Responsibilities

• Security & Compliance Team: Owns PCI DSS oversight, risk assessments, and coordinates with acquiring banks and QSAs if applicable.
• Engineering: Ensures secure integrations, segmentation, logging, and remediation of findings.
• Support & Operations: Follows secure handling procedures; never requests or records CVV or full PAN.
• Vendors/Processors: Must maintain appropriate PCI DSS level of compliance and provide Attestation of Compliance (AOC) upon request.

3. Data Classification & Minimization

• Cardholder Data (CHD): PAN with cardholder name, expiry; treated as sensitive; not stored by Upmos.
• Sensitive Authentication Data (SAD): CVV/CVC, PIN, track data; never stored or logged.
• Minimization: Collect only what is necessary for transaction processing; prefer tokens from providers.

4. Prohibited Data Storage

• No storage of CVV/CVC, PIN, or magnetic stripe/track data.
• No storage of full PAN post-authorization; only provider tokens or truncated PAN (first 6 / last 4) when needed.
• No logging of PAN or SAD in application, server, or analytics logs.

5. Payment Data Flow & Providers

• Payments are processed via PCI DSS-compliant gateways; Upmos leverages tokenization to avoid CHD storage.
• Web and mobile clients submit payment details directly to the provider via client-side SDKs where possible.
• Provider AOCs and penetration test summaries are reviewed at least annually.

6. Encryption & Key Management

• Provider tokens are stored; no internal PAN storage. Any rare PAN handling must use strong encryption (AES-256) and be approved by Security.
• Keys managed centrally with access controls, rotation, and separation of duties.
• Private keys are stored in secure keystores/HSM-equivalent services; never in code or repos.

7. Transmission Security

• TLS 1.2+ required for all payment and sensitive data in transit; strong ciphers, forward secrecy preferred.
• HSTS enforced at the edge; certificates managed with automated renewals.
• No insecure fallbacks (e.g., HTTP, old SSL/TLS versions).

8. Access Control & Authentication

• Least privilege for all systems impacting payments; role-based access; periodic reviews.
• MFA required for admin, support, and engineering consoles.
• Unique user accounts; no shared credentials; immediate revocation on role change/termination.

9. Logging & Monitoring

• Centralized logging for authentication, authorization, configuration changes, and payment events.
• Alerting on anomalous access, failed logins, privilege escalations, and suspected data access.
• Log retention meets legal and security requirements; logs are protected from tampering.
• Time synchronization across systems via secure NTP; timestamps are normalized to enable reliable correlation and forensic analysis.
• Immutable storage or write-once protections are applied to critical audit logs; access to logs is restricted and audited.

10. Network & Endpoint Security

• Segmentation between public-facing systems and any components that could touch payment flows.
• Firewalls and security groups enforce least access; only required ports exposed.
• Endpoint protections (EDR/AV) on servers and workstations used for administrative access.

11. Vulnerability Management & Patching

• Regular vulnerability scanning; critical findings remediated promptly.
• Patch management with defined SLAs based on severity; emergency patch process for zero-days.
• Dependency management to reduce exposure to known vulnerabilities.

12. Secure Development & Change Management

• Secure SDLC with code review and security checks for payment-related changes.
• Secrets never committed to source control; stored in managed secret stores.
• Changes follow approval and rollback procedures; production access controlled and audited.

13. Incident Response & Breach Notification

• Documented IR plan covering identification, containment, eradication, recovery, and postmortem.
• Suspected payment data incidents are escalated immediately to Security and payment providers.
• Customers and regulators notified as required by law and contractual obligations.

14. Data Retention & Disposal

• No storage of CHD or SAD. Tokens retained per business need and provider agreements.
• Backup data excluded from CHD; if any CHD is discovered, it is securely purged.
• Media and documents are destroyed using secure methods aligned with data classification.

15. Third-Party Service Providers

• Providers handling payment data must maintain PCI DSS compliance; AOCs collected and reviewed annually.
• Data processing agreements and security addenda required; right to audit/security questionnaire reserved.
• Access limited to least privilege; integrations reviewed for secure configurations.

16. Business Continuity & Backups

• Backups exclude sensitive authentication data; encryption applied at rest and in transit.
• Disaster recovery plans tested periodically; recovery time objectives documented.

17. Physical Security

• We use cloud and processor infrastructure with documented physical security controls (data center access controls, surveillance, visitor management).
• Corporate devices used for admin access follow asset management, encryption, and screen lock requirements.

18. Testing & Assessments

• Regular vulnerability scans; periodic penetration tests for external-facing services.
• Findings are tracked to remediation with defined timelines based on severity.
• Security reviews required for material changes to payment flows.
• Segmentation tests validate isolation of the cardholder data environment from other networks/systems.
• Assessment cadence includes quarterly scans and at least annual penetration testing, plus testing after significant changes.