Summary

AICSUITE handles sensitive information — including Social Security Numbers, banking details, and payroll data — on behalf of service businesses and their workforces. Security is foundational to the product, not a feature bolted on after the fact. This document describes how we protect data at the infrastructure, application, and operational layers.

Key facts:

• AES-256 encryption at rest for sensitive identifiers (SSNs, banking data);
• TLS 1.2+ encryption in transit for all connections;
• Row-Level Security (RLS) enforced at the database layer for tenant isolation;
• Five-tier role-based access control with least-privilege defaults;
• 72-hour breach notification commitment to customers;
• SOC 2 Type II attestation in active pursuit.

1. Infrastructure

AICSUITE runs on industry-leading managed cloud infrastructure operated by providers with their own mature security programs.

• Application hosting — AWS Amplify in U.S. regions, with AWS's underlying SOC 2, ISO 27001, and PCI DSS certifications;
• Database, authentication, and storage — Supabase (managed PostgreSQL 15) with at-rest encryption and isolated tenant schemas;
• AI inference — AWS Bedrock for cloud-based AI features; Customer Data is not used to train third-party foundation models;
• CDN, DNS, and DDoS protection — Cloudflare;
• Payments — Stripe (PCI DSS Level 1 certified); AICSUITE does not store full card numbers.

Network access between components is restricted to authenticated, least-privilege paths over TLS.

2. Encryption

2.1 Encryption at Rest

• Database storage volumes are encrypted by the cloud provider;
• Sensitive identifier columns (Social Security Numbers, banking account numbers) are additionally encrypted at the application layer using AES-256-GCM;
• Encryption keys are stored in a managed key-management service, separated from the encrypted data;
• Backups are encrypted with the same standards as production data.

2.2 Encryption in Transit

• All public endpoints require TLS 1.2 or higher;
• HSTS is enabled for our web origins;
• Internal service-to-service traffic and database connections use TLS.

3. Access Control

3.1 Tenant Isolation

Every tenant's data is logically isolated by organization identifier. Isolation is enforced by PostgreSQL Row-Level Security (RLS) policies, so that even direct database queries cannot return data from another tenant.

3.2 Role-Based Access Control

AICSUITE uses a five-tier role hierarchy:

• Administrator — full administrative authority over the organization (org settings, billing);
• Manager — operational leadership (payroll, reports, user management);
• Staff — day-to-day operations;
• Contractor — restricted self-service portal access only;
• User — public/customer-facing role with no operational access.

Permissions are enforced at the route, server-action, and database levels. Roles are synced from PostgreSQL to JWT app metadata.

3.3 Principle of Least Privilege

Internal AICSUITE personnel access to production systems is granted on a least-privilege basis, audited, and revoked promptly upon role change or termination. Administrative access to encrypted SSN fields is restricted to a narrow set of authorized personnel and operations.

4. Authentication

• Supabase Auth with industry-standard password hashing;
• JWT-based session tokens with short lifetimes and automatic refresh;
• Multi-Factor Authentication (MFA) available for all accounts and strongly recommended for Administrators and Managers;
• Password complexity requirements and protection against credential stuffing.

5. Application Security

• Secure SDLC — peer code review, type-checked TypeScript, and automated lint/format checks before merge;
• Input validation at server entry points; parameterized queries to prevent SQL injection;
• CSRF and XSS protections via framework defaults and content-security-policy headers;
• Dependency management — automated vulnerability scanning of third-party libraries;
• Secrets management — credentials and API keys stored in environment-isolated secret managers, never in source control.

6. Monitoring and Logging

• Centralized logging of application errors, authentication events, and administrative actions;
• Cloud-provider infrastructure logs (AWS CloudWatch, Cloudflare, Supabase);
• Alerting on anomalous behavior such as repeated failed authentications, privilege escalations, and unusual data-access patterns;
• Audit-log retention sufficient to support incident investigation.

7. Incident Response

AICSUITE maintains a documented incident-response process:

1. Detect — through monitoring, alerts, customer reports, or security researcher disclosures;
2. Triage — classify severity and assemble a response team;
3. Contain — isolate affected systems and limit blast radius;
4. Eradicate — remove the underlying cause;
5. Recover — restore services and verify integrity;
6. Notify — provide breach notification to affected customers within 72 hours of confirming a Personal Data Breach;
7. Learn — conduct a post-incident review and implement improvements.

8. Business Continuity and Disaster Recovery

• Automated, encrypted database backups taken on a regular schedule by the managed database provider;
• Backup-restore procedures tested periodically;
• Infrastructure-as-code configuration enabling timely rebuild of application environments;
• Recovery objectives are reviewed annually against business needs.

9. Vendor and Subprocessor Management

AICSUITE selects subprocessors with mature security programs, executes written agreements that include data-protection obligations no less protective than our DPA, and maintains an up-to-date Subprocessors list. Material new subprocessors are noticed to customers with the opportunity to object.

10. Personnel Security

• Confidentiality obligations for all personnel;
• Security and privacy awareness training for personnel with access to Customer Data;
• Access reviews following role changes and prompt revocation on offboarding;
• Background checks for personnel in roles with privileged access, where permitted by law.

11. Compliance Roadmap

AICSUITE is actively building toward formal certifications:

• SOC 2 Type II — attestation in active pursuit. We are operationalizing the Trust Services Criteria (Security, Availability, Confidentiality) and intend to complete a Type I report followed by a Type II observation period;
• GDPR / UK GDPR — addressed via our DPA, Standard Contractual Clauses, and the privacy practices described in our Privacy Policy;
• CCPA / CPRA and U.S. state privacy laws — addressed via our Privacy Policy and a Data Subject Request workflow;
• HIPAA — not currently in scope. The Services are not designed to store Protected Health Information and a Business Associate Agreement (BAA) is not offered;
• PCI DSS — out of scope for AICSUITE; payment card data is handled by Stripe.

12. Responsible Disclosure / Security Contact

We welcome reports from security researchers and customers. If you believe you have found a security vulnerability, please email security@aicsuite.com with a detailed description, steps to reproduce, and any supporting material. Please:

• Provide us a reasonable opportunity to investigate and remediate before public disclosure;
• Avoid actions that may disrupt the Services, access data that is not your own, or violate applicable law;
• Do not engage in social engineering of AICSUITE personnel or customers.

We will acknowledge reports and work with researchers in good faith.