Security is foundational to Pocket Theory HQ. Your operators trust us with member data, payment integration credentials, and identity documents. Here's exactly how we protect that trust.
All services run in Amazon Web Services, North Virginia region. Compute, database, and storage are isolated within a private VPC with no public ingress except load balancers.
Primary database hosted on AWS RDS with multi-AZ standby, automated backups retained for 7 days, and encryption at rest using AES-256.
Stateless API and web console run on AWS App Runner. Background workers run on ECS Fargate. No persistent container state; each deploy starts fresh.
All production secrets (database credentials, API tokens, encryption keys) are stored in AWS SSM with KMS encryption. No secrets in environment variables or source code.
All communication between clients and the Pocket Theory HQ API uses TLS 1.2 or higher. The Android app, web console, and API worker all enforce encrypted connections. The database connection uses TLS with certificate verification against the AWS RDS Certificate Authority bundle — we do not use self-signed or unverified TLS.
The RDS database is encrypted at rest using AES-256 managed by AWS KMS. S3 buckets containing logs and state are server-side encrypted. Clover OAuth tokens stored in the database are encrypted using AES-256-GCM before persistence, using a dedicated key stored in SSM.
Staff authenticate to the Pocket Theory HQ platform via time-limited Bearer tokens issued after PIN verification. PINs are stored as salted scrypt hashes — plaintext PINs are never stored or logged. Tokens expire and must be re-issued. Clover OAuth tokens are stored encrypted and refreshed automatically using a refresh-token rotation pattern with advisory-lock protection against concurrent refresh races.
Access is role-gated at every endpoint. Three roles — STAFF, MANAGER, OWNER — have distinct permission sets enforced in API middleware. Subscription tier (BASIC, PRO, PREMIUM) is enforced as a separate gate on top of role: a MANAGER on a BASIC tier cannot access PRO features regardless of role. All authorization decisions are logged.
Incoming Clover webhooks are verified using HMAC-SHA256 signatures. We fail closed — unsigned or invalid webhooks are rejected with a 401, not processed. Replay attacks are mitigated by recording and deduplicating processed event IDs.
API inputs are validated using Zod schemas at every route boundary. SQL queries use parameterized statements — no string interpolation in query construction. HTTP responses redact internal stack traces; errors return sanitized messages only.
The web console sets a strict Content Security Policy, HSTS with a 1-year max-age, X-Frame-Options DENY, and X-Content-Type-Options nosniff on all responses.
The PRO tier's ID-scan check-in feature reads AAMVA-format PDF417 barcodes from driver's licenses. We take deliberate steps to minimize exposure of this sensitive data:
Production systems are accessible only via SSH key authentication — no password SSH. The RDS database is in a private subnet with no public endpoint. Access from engineer workstations requires an explicit VPC bastion or one-shot ECS task. All production access is logged.
IAM roles for each service component (API, worker, web console) have scoped policies: read-only where possible, no cross-service lateral movement. The API's IAM role cannot access the worker's secrets, and vice versa.
Every state-changing operation in the platform — session lifecycle transitions, member data changes, override approvals, rate plan modifications, staff role changes — is written to an immutable audit log with actor identity, timestamp, and before/after state. This log is append-only; past entries cannot be modified or deleted through the application layer.
We run CloudWatch alarms on API error rates, latency spikes, and worker health. Alarm events route to an SNS topic that pages the on-call engineer. Our target is to acknowledge critical incidents within 1 hour and communicate status to affected operators within 4 hours.
In the event of a data breach affecting your merchant account or member data, we will notify you as required by applicable law and as soon as practicable after we confirm the incident.
If you discover a security vulnerability in Pocket Theory HQ, please report it responsibly to security@pockettheoryhq.com. We commit to acknowledging valid reports within 2 business days and resolving confirmed critical vulnerabilities within 30 days. We do not take legal action against good-faith researchers who follow responsible disclosure practices.
When reporting, please include:
Please do not access or modify data belonging to other merchants, execute denial-of-service attacks, or publicly disclose the vulnerability before we have had a reasonable opportunity to address it.
Pocket Theory HQ integrates with Clover (Fiserv) for payment processing. Payment card data never passes through our systems — all card transactions are handled by Clover's PCI-compliant infrastructure. We are not a PCI merchant. Our handling of payment data is limited to order IDs and line-item references returned by Clover's API after a transaction completes.
We review dependencies for known vulnerabilities as part of our development workflow and apply security patches to critical dependencies on an expedited basis.
For vulnerability reports, security questions, and incident notifications. PGP key available on request.