Compliance Center

Security & Compliance Program

Policies, risk register, and vendor assessments that govern how EcoService Pro protects customer data. This page is maintained by EcoPowerHub AI LLC for prospects, auditors, and internal review. For disclosures contact engmartin@ecopowerhub.ai.

Access Control Policy

Version: 1.0 · Effective: July 14, 2026 · Owner: Security Lead

1. Purpose

Ensure that only authenticated, authorized identities can access EcoService Pro systems and data, and that access is proportionate to job function.

2. Identity lifecycle

| Event | Action | SLA | | --- | --- | --- | | Onboarding | Provision least-privilege account, require MFA on first login | Day 1 | | Role change | Re-evaluate access; revoke what is no longer needed | 5 business days | | Offboarding | Disable auth, revoke tokens, rotate shared secrets | Same day | | Quarterly review | Owner audits all admin / owner roles | Every 90 days |

3. Authentication

  • Email + password with HIBP leaked-password check enforced (Supabase Auth).
  • Minimum 12 characters, complexity checked by the provider.
  • MFA (TOTP) required for all owner and admin roles; strongly recommended for member.
  • SSO / social login via Google is permitted; the underlying account must still respect MFA.
  • Session lifetime: 24 h sliding refresh, 30 d absolute max. Idle sessions revalidated on privileged actions.

4. Authorization model

  • Roles stored in public.user_roles (never on the profiles table) — enforced by has_role(uid, role) SECURITY DEFINER function.
  • Row-Level Security is enabled on every table in the public schema. CI test supabase/tests/roles_and_rls.sql fails the build if a table is missing RLS or a policy.
  • Service-role key is never used from route/serverFn module scope; it is loaded only inside verified webhook handlers or admin maintenance code (*.server.ts).
  • Public API endpoints under /api/public/* verify HMAC signatures before any write.

5. Privileged access

  • Only the CEO and Security Lead hold owner role on production.
  • Admin actions are logged to audit_logs with actor, IP, user agent, and diff.
  • Break-glass access requires written approval and post-hoc review within 24 h.

6. Third-party & vendor access

  • Vendors receive scoped API keys, never shared user credentials.
  • All vendor access is enumerated in vendors/assessments.md and reviewed annually.

7. Enforcement

Failed logins are rate-limited (rate_limit_buckets). Repeated failures trigger a security_events entry visible on /security. Suspected credential compromise → force password reset + session revoke.

Version-controlled source of truth for this document lives in the project repository. Material changes are reviewed by the Security Lead and approved by the CEO.