Security at Yusker

• Card numbers are tokenized — full card numbers are never stored on our servers, on your device, or in our logs. We retain only an opaque token plus the card brand and last four digits.
• Sensitive authentication data (such as the CVV) is never stored after authorization — by design, our systems have no field in which to hold it.
• Where card data is handled, it is confined to a dedicated, isolated cardholder data environment (CDE), separated from the rest of the platform.
• Card processing runs through a PCI DSS Level 1–validated payment processor; we inherit and track their attestations as part of our third-party program.

• Data is encrypted in transit with TLS 1.2+ and at rest with AES-256.
• Our own internal services authenticate to one another with mutual TLS (mTLS).
• Encryption keys are protected by a FIPS 140-2 Level 3 hardware security module (HSM). Key material is generated inside the HSM and never leaves it.
• The HSM is activated and recoverable only under a split-knowledge, dual-control key ceremony — no single individual can access or export it.
• We use envelope encryption: each record is sealed with its own data key, which is itself wrapped by the key held in the HSM.
• Signing secrets are versioned so they can be rotated without disrupting service — rotation is a routine operation, not an emergency procedure.

• The cardholder data environment runs in its own isolated network segment with default-deny controls — only explicitly authorized traffic is permitted.
• Sensitive systems are not reachable from the public internet; they are accessed over private connectivity only.
• Outbound access from the payment environment is restricted to an approved allow-list — including its telemetry, which leaves over private connectivity with zero internet egress.
• A web application firewall inspects traffic at the platform edge.

• Two-factor authentication (2FA) protects administrative, business-owner, and staff access; administrative access to internal systems additionally goes through single sign-on.
• Access follows the principle of least privilege: people and services receive only the permissions their role requires, enforced by role-based access control.
• Every user has a unique identity; sessions are short-lived, idle sessions time out automatically, and access is revocable at any time. Strong password requirements are enforced.
• No individual has standing access to cryptographic material — key operations are performed by service identities under dual control.

• All code is under version control, with peer-reviewed, change-controlled deployments.
• Dependencies, code, and configuration are scanned on a defined schedule — dependency vulnerabilities, static analysis, and secret detection — with results retained as evidence.
• Systems are built from hardened, minimal-footprint configurations.
• Content-security and related browser protections are deployed on customer-facing surfaces.

• Security-relevant events from all production systems — including the isolated payment environment — flow to centralized, tamper-resistant log storage with at least 12 months of retention.
• Automated detection rules and intrusion-detection controls alert the security team to suspicious activity; alerting on monitoring-pipeline failure is itself monitored.
• Endpoint detection & response (EDR) and anti-malware protection run across production systems, with file-integrity monitoring on sensitive configuration.
• Sensitive actions are captured in append-only audit logs for accountability and forensics.
• We maintain a documented incident-response plan with assigned roles, and a defined process to detect, contain, and remediate security events.

• Recurring vulnerability scanning runs across the codebase and its dependencies, with a defined severity-based remediation SLA.
• External vulnerability scanning by a PCI-approved scanning vendor (ASV) and independent penetration testing — including segmentation testing of the payment environment — are being procured as part of our assessment path.
• Findings are tracked in a remediation backlog with owners and priorities, reviewed on a business-as-usual calendar.

• A complete information-security policy set governs the program: access control, cryptography, change management, acceptable use, retention and disposal, network security, secure development, and more.
• Security roles are formally assigned — an executive sponsor, a security program lead, and named key custodians under dual control.
• A security-awareness program and defined onboarding/offboarding procedures cover everyone with access.
• Risk assessments and targeted risk analyses are performed and documented, with a business-as-usual review calendar keeping scope and controls current.

• A data-retention and disposal policy defines what we keep, for how long, and how it is destroyed.
• Personal data is handled in line with applicable privacy laws, with documented processes for data-subject requests.
• Encrypted backups and recovery procedures protect against loss; media handling and physical protections for our infrastructure are inherited from our hosting providers' audited controls and verified through their attestations.

A program-level view of how our controls align to the twelve PCI DSS requirement families. The detailed control-by-control compliance matrix, including current remediation status, is part of the NDA-gated documentation set.

• Card processing is performed through a PCI DSS Level 1–validated payment processor; physical infrastructure runs with major cloud providers whose independent audit attestations we collect and review.
• Third-party service providers are tracked in a responsibility matrix that records which PCI DSS requirements each provider covers and which remain ours.
• The identity of specific providers, and their attestations of compliance, are shared with assessors under NDA.