Security Overview
Keme SupportOps is built on a security-first architecture. We believe that gaming studios and digital publishers trust us with sensitive operational data, and that trust must be earned through demonstrable controls, not just policy statements.
This document covers the technical and procedural security measures in place as of the date shown above. We update it whenever significant changes are made to our security posture.
Technical Controls
Encryption
All data stored within Keme SupportOps is encrypted at rest using AES-256-GCM. Database encryption keys are managed via envelope encryption: a data encryption key (DEK) is generated per tenant, wrapped with a key encryption key (KEK) stored in a hardware-backed key management system (KMS).
All data in transit is protected using TLS 1.2 at minimum, with TLS 1.3 preferred. We enforce HSTS with a max-age of 1 year and preload. Certificate transparency is enforced.
Input Validation
All API endpoints perform server-side input validation. User-submitted content is sanitised to prevent XSS, SSRF, and SQL injection attacks. Parameterised queries are used throughout the data layer. File upload endpoints enforce strict MIME type checking and maximum file size limits.
Dependency Management
We run automated dependency scanning on every pull request and weekly full scans. Critical and high-severity vulnerabilities are remediated within 7 and 30 days respectively. We maintain a software bill of materials (SBOM) for all production services.
Infrastructure Security
Cloud Infrastructure
Keme SupportOps runs on cloud infrastructure with all services deployed within private networks. Public-facing traffic is filtered through a WAF (Web Application Firewall) and DDoS-mitigation layer before reaching application servers. No service ports are exposed to the public internet except 443 (HTTPS) and 22 (SSH, restricted to known IPs via allowlist).
Network Isolation
Application, database, and cache tiers are isolated in separate network segments with explicit allow-list rules. Database servers have no direct internet access. All cross-tier communication is authenticated using mTLS.
Container Security
All production workloads run in hardened containers with read-only root filesystems, dropped capabilities, and seccomp profiles. Base images are scanned on build and weekly. We use minimal base images (distroless where possible) to reduce attack surface.
Backups
Daily encrypted backups are taken and stored in a geographically separate region. Backups are retained for 30 days. Restoration procedures are tested quarterly. Backup files are encrypted using the same AES-256 approach as production data.
Access and Identity
Role-Based Access Control (RBAC)
Access to customer data is governed by RBAC. Roles are: Owner, Admin, Agent, and Read-Only. Each role has a minimum set of permissions required for its function. Permissions cannot be granted beyond the caller's own permission level.
Authentication
All accounts are protected with password hashing using bcrypt (cost factor 12). Multi-factor authentication (MFA) is available and strongly recommended for all workspace owners and admins. SSO via SAML 2.0 and OIDC is available on Enterprise plans.
Internal Access
Keme employees access production systems only via VPN and MFA-enforced access controls. Access to production data is limited to engineers with a specific operational need. All internal access is logged. Production access is reviewed quarterly with a process of removing access when no longer needed.
Session Management
Platform sessions expire after 24 hours of inactivity. All active sessions are visible and terminable from the user's account settings. Concurrent session limits apply per plan.
Data Security
We operate a strict data segregation model. Each operator workspace is logically isolated with row-level security enforced at the database layer. An operator can only access data that belongs to their own workspace — even if they share underlying infrastructure.
AI Copilot features are trained exclusively on each operator's own ticket data. No cross-tenant data mixing occurs in model training or inference. Operators may request deletion of their training data at any time.
For more on data handling, see our Privacy Policy.
Monitoring and Logging
All authentication events, permission changes, API calls, and data exports are logged to a tamper-evident audit log. Logs are written to an immutable append-only store. Access to audit logs themselves is restricted and logged.
We run continuous anomaly detection across authentication, API usage, and data access patterns. Alerts are routed to the security on-call team with SLA-based response times.
Uptime and performance are monitored with synthetic probes every 60 seconds from multiple regions. Status is published at status.kemegames.com.
Incident Response
Classification
Security incidents are classified as Critical (data breach or unauthorised access), High (potential exposure, service degradation), Medium (attempted attack, policy violation), or Low (suspicious activity, misconfiguration).
Response SLA
| Severity | Acknowledge | Initial response | Resolution target |
|---|---|---|---|
| Critical | 1 hour | 4 hours | 24 hours |
| High | 4 hours | 24 hours | 7 days |
| Medium | 24 hours | 72 hours | 30 days |
| Low | 48 hours | 7 days | 90 days |
Customer Notification
In the event of a confirmed security incident that affects customer data, we will notify affected operators within 72 hours of confirmation, in compliance with GDPR Article 33 requirements. Notifications will be sent to the primary account email and the platform notification centre. Notifications will include the nature of the incident, data categories affected, likely consequences, and remediation steps taken.
Responsible Disclosure
We welcome responsible disclosure of security vulnerabilities. If you discover a security issue in the Keme SupportOps platform or website, please report it to us before publishing it publicly.
Our Commitments
- We will acknowledge your report within 24 hours
- We will provide a detailed response within 72 hours indicating our assessment and next steps
- We will not take legal action against researchers acting in good faith under this policy
- We will credit researchers in our security acknowledgements (with permission)
- We will notify you when the vulnerability has been resolved
Scope
In-scope: kemegames.com, app.kemegames.com, API endpoints, and mobile clients (when launched). Out-of-scope: third-party services we integrate with, social engineering attacks, denial-of-service attacks, and physical security attacks.
Compliance and Certifications
- SOC 2 Type II — in progress, audit scheduled Q3 2026
- GDPR — compliant; DPA available on request; UK ICO registered
- PCI DSS — not a card processor; we use a PCI-certified payment provider (Stripe)
- ISO 27001 — planned for 2027
We are happy to provide a completed security questionnaire or share our in-progress SOC 2 report under NDA for Enterprise customers. Contact security@kemegames.com.