Security at SupportCore

1. Overview

SupportCore is a multi-tenant customer support platform operated by Lord Systems, LLC. Our customers entrust us with their support inboxes, knowledge base content, and the contact information of their end-users. We treat that trust as the product.

This page describes the technical, organizational, and procedural controls we have in place. It applies to the production environment of the Service. If you have a question this page does not answer, contact security@supportcore.io.

2. Shared responsibility model

Cloud security is a shared responsibility. Roughly:

3. Infrastructure

3.1 Hosting

The SupportCore application runs on Cloudflare's global edge platform, including Cloudflare Workers, D1, and Durable Objects for compute, and Cloudflare R2 for object storage. Cloudflare's data centers are SOC 2 Type II, ISO 27001, ISO 27018, and PCI DSS compliant.

3.2 Network

All traffic to the Service is served behind Cloudflare's WAF and DDoS protection. Origin systems are not directly reachable from the public internet; only signed, mTLS-authenticated requests from Cloudflare can reach origin services.

3.3 Tenancy

SupportCore is a logically multi-tenant SaaS. Workspace data is isolated by per-row tenant identifiers, which are enforced in the data access layer and validated at request time. Cross-tenant access is not possible through the application API.

3.4 Regions

Workspaces are pinned to a primary processing region (currently US or EU). Customer Data at rest does not leave its primary region except for encrypted backups, which are replicated to a paired region for durability.

4. Encryption

4.1 In transit

• All connections to the Service use TLS 1.2 or higher with modern cipher suites; older protocols are disabled.
• HSTS is enabled with preload, including subdomains.
• Internal service-to-service traffic is mTLS-authenticated.

4.2 At rest

• Database storage is encrypted at rest with AES-256.
• Object storage (attachments, exports) is encrypted at rest with AES-256.
• Backups are encrypted with separately-managed keys.
• Application secrets are stored in a managed secrets store and never written to source control or container images.

4.3 Key management

Encryption keys are managed by our cloud provider and rotated periodically. Customer-managed encryption keys (CMEK) are available on Enterprise plans.

5. Authentication and access controls

5.1 Customer-side authentication

• Passwords are hashed with Argon2id.
• Two-factor authentication (TOTP) is available on every plan and required for Owner and Admin roles by default.
• Session tokens are HttpOnly, Secure, SameSite=Lax, and rotated on privilege change.
• Workspaces can require IP allowlisting and force re-authentication for sensitive actions.
• SSO (SAML 2.0 or OIDC) is available for the customer portal via Auth0 and on the agent application for Business and Enterprise plans.

5.2 Internal access

• Production access is restricted to a small number of authorized engineers on a need-to-know basis.
• All production access requires SSO + hardware-key second factor (FIDO2).
• Privileged actions are time-bound and reviewed monthly.
• SupportCore staff do not access Customer Data except as required to provide support, debug an incident, or comply with law. All such access is logged and reviewable.

5.3 Role-based access (RBAC)

Within a workspace, roles include Owner, Admin, Agent, and Limited Agent. Limited Agents can be scoped to specific workspaces, channels, or tag sets. Audit logs capture all administrative changes.

6. Application security

• Input validation at API boundaries, with strict schemas.
• Output encoding to prevent XSS in agent and customer surfaces; Content-Security-Policy headers in place.
• Parameterized queries exclusively — no dynamic SQL string concatenation.
• CSRF protection via SameSite cookies and per-form tokens.
• Rate limiting on authentication, API, and webhook endpoints, with per-tenant and per-IP buckets.
• Webhooks outbound from the Service are signed with HMAC-SHA256 over the raw request body, with a timestamp to prevent replay.
• Attachment scanning — uploads are scanned for malware before being made available.
• Dependency scanning — automated CI checks for known-vulnerable dependencies on every pull request and nightly.
• Static analysis (SAST) runs in CI on every change. High-severity findings block merge.
• Container image scanning for production builds.

7. Secure development lifecycle

• All code changes go through pull-request review with at least one second engineer.
• Automated tests run on every change before merge.
• Production deployments are gated on CI passing and require approval for sensitive surfaces (auth, billing, data access).
• Infrastructure is managed as code and reviewed under the same process.
• Production secrets are scoped per environment and rotated on personnel change.

8. Data handling

8.1 Customer Data isolation

Customer Data is logically isolated per workspace. We do not commingle data across customers in shared columns, and tenant scoping is enforced in the data access layer.

8.2 Backups

We take continuous backups of production datastores. Backups are encrypted, tested via periodic restore drills, and retained on a 30-day rolling schedule.

8.3 Deletion

When a workspace is deleted, Customer Data is removed from active systems within 30 days and purged from backups within 60 days. Specific deletion of an individual record (for example, a contact's data subject request) takes effect in active systems immediately.

8.4 Data minimization

We do not require, request, or store sensitive categories of personal information (government IDs, payment card numbers, protected health information, biometric data). Customers should not upload such data to the Service.

9. Sub-processor security

Before we engage a sub-processor that may handle Customer Data, we evaluate its security posture, certifications, and contractual commitments. Our current sub-processors are listed in our Privacy Policy. We require sub-processors to enter into data processing terms substantively equivalent to ours.

10. Monitoring and logging

• Application and infrastructure logs are centralized and retained for at least 90 days.
• Authentication events, administrative changes, and data-access events are logged separately and retained for at least one year.
• Anomaly detection alerts the security team on suspicious patterns (impossible-travel logins, brute-force attempts, sudden export spikes).
• Customers can review workspace audit logs from within the application.

11. Incident response

We maintain a documented Incident Response Plan that defines roles, severity levels, communication paths, and post-incident review. The plan is rehearsed at least annually.

In the event of a confirmed Personal Data Breach (as defined under GDPR Art. 4) affecting a Customer's data, we will notify the affected Customer without undue delay and in any event within 24 hours of confirmation. Notifications include the nature of the breach, the categories and approximate volume of records affected, the likely consequences, and the measures we are taking. We will keep the Customer updated as the investigation progresses.

12. Business continuity & disaster recovery

Our recovery objectives for the production Service:

• Recovery Time Objective (RTO): 4 hours
• Recovery Point Objective (RPO): 1 hour

Production systems are deployed across multiple availability zones. We perform restoration drills at least once per year and review the BC/DR plan annually or after material changes.

Real-time service availability is published at status.supportcore.io.

13. People and training

• All personnel pass background checks where permitted by law.
• All personnel sign confidentiality agreements.
• Mandatory annual security and privacy training, plus role-specific training for engineers (secure coding) and support (data-handling).
• Access is provisioned based on least privilege and reviewed quarterly. Access is revoked on the same day as termination.

14. Compliance and certifications

We are designed to support customers' GDPR, UK GDPR, and CCPA/CPRA obligations. We provide a Data Processing Addendum incorporating the EU Standard Contractual Clauses (2021/914) on request.

Certifications and audits:

15. Penetration testing

We engage a reputable independent firm to perform a black-box and authenticated penetration test of the Service at least annually, and after material architectural changes. A summary report is available to customers under NDA on request to security@supportcore.io.

Customers may perform their own non-disruptive security testing of their own workspace, subject to our Vulnerability Disclosure Policy. Coordinated tests against the production environment require advance written approval.

16. Vulnerability disclosure policy

We welcome reports from the security community. If you believe you have found a security vulnerability in SupportCore, please report it as described below. We commit to:

• Acknowledge your report within 3 business days.
• Provide a substantive response within 10 business days with our triage assessment.
• Keep you informed of remediation progress.
• Credit you in our security acknowledgements (with your permission) once the issue is resolved.
• Not pursue legal action against good-faith researchers who comply with this policy.

Scope

In scope:

• *.supportcore.io production environment
• The SupportCore REST API and webhook implementation
• The SupportCore JavaScript chat widget

Out of scope:

• Marketing site (this site, supportcore.io) other than vulnerabilities that would compromise customer accounts
• Findings from automated scanners without demonstrable impact
• Social engineering, phishing, or physical attacks on SupportCore staff
• Denial-of-service testing of any kind
• Issues in third-party services (report directly to that vendor)
• Self-XSS, missing security headers without exploitable impact, clickjacking on pages without state-changing actions

We do not currently offer monetary bounties; this is a coordinated disclosure program.

17. Report a security issue

Email: security@supportcore.io

PGP key: Available on request. Please mention "PGP key request" in the subject line.

For non-security inquiries, please use the appropriate contact in our Privacy Policy or open a support ticket from inside the application.

Thank you for helping us keep SupportCore safe.