Security at SLTax360

Surplus lines filing data sits inside a compliance perimeter — policy details, premium and tax breakdowns, insured information, audit trails. Here are the operational controls we run today to keep that data protected, isolated per tenant, and recoverable.

Operational Controls

Encryption in transit

All traffic to and from sltax360.com and every tenant subdomain is served over TLS 1.3 with auto-renewing certificates (Let's Encrypt, HTTP-01 webroot). HTTPS is enforced; HTTP is redirected. HSTS recommended for enterprise plans.

Encryption at rest

Customer documents stored in AWS S3 use SSE-S3 (AES-256). MariaDB volumes sit on encrypted EBS. Database backups inherit volume-level encryption.

No static cloud keys in production

Production servers authenticate to AWS S3 and SES via IAM instance roles attached to the EC2 host. There are no AWS_ACCESS_KEY_ID values on disk in production, and no static access keys for the application's IAM principal.

Centralised secret management

All application secrets — database passwords, third-party API keys, webhook signing secrets — are stored in AWS SSM Parameter Store under /sltax360/* and fetched on boot. Secrets never appear in phpinfo, environment dumps, or version control.

Data residency

Primary application and database infrastructure runs in AWS us-east-2 (Ohio). Document storage is regional. We do not replicate customer data outside the United States.

Multi-tenant isolation

Each tenant is provisioned on a dedicated database (sltax_tenant_*) selected at request time via subdomain. Cross-tenant queries are not possible through the application layer; row-level mixing is architecturally prevented.

Authentication & abuse

Login uses salted password hashing, exponential brute-force back-off, and Google reCAPTCHA v3 on signup, login, demo, contact, and API access forms. Per-IP rate limits apply to public form submissions and the calculator.

Backups & recovery

Per-tenant database snapshots run on an automated schedule and are retained for operational recovery. Disaster-recovery procedures are documented and exercised by the engineering team. Restore SLAs are scoped per plan.

Secret scanning in CI

A gitleaks pre-commit hook scans every commit for credentials. Any match blocks the commit. Historical credential exposure has been remediated and rotated.

Internal area protections

Apache .htaccess rules block direct access to dotfiles, SQL dumps, configuration files, and known sensitive paths. Internal endpoints (/superadmin, /customer-service, worker URLs) are excluded from search-engine indexing.

Subprocessors

Vendors with access to customer-bearing data flows. We update this list when subprocessors change.

Vendor Purpose Data exposure Region
Amazon Web Services Hosting (EC2), object storage (S3), transactional email (SES), secret store (SSM) All customer data (encrypted at rest) us-east-2
OpenAI Document OCR and structured-data extraction for invoices submitted through the email-ingest pipeline Invoice document images / extracted text only. Used solely for parsing; not used to train models. OpenAI cloud (US)
Google reCAPTCHA v3 Bot-and-abuse scoring on signup, login, demo, contact, and API access forms IP, browser fingerprint signals (no surplus-lines content) Google global
Let's Encrypt TLS certificate issuance for sltax360.com and tenant subdomains Domain names only Global

OpenAI usage is limited to the email-ingest invoice OCR pipeline. Manual uploads, REST API submissions, and state-filing flows do not route through OpenAI.

Found a Security Issue?

Please email security@sltax360.com with a reproduction. We acknowledge within 2 business days. We will not pursue good-faith researchers who follow standard responsible-disclosure norms (no data exfiltration, no service degradation, no public disclosure before remediation).

security@sltax360.com

Have an Enterprise Security Questionnaire?

Send it over — our team typically returns completed CAIQ-style questionnaires within five business days.