Information Security, Access Control & Data Retention

A.1 Purpose

Protect the confidentiality, integrity, and availability of all information assets managed by the Flux Energy platform, including SCADA data, financial records, PII, and operational telemetry.

A.2 Scope

All systems, data, users, and third-party integrations within the Flux Energy platform environment: web application, API server, PostgreSQL database, deployment infrastructure (for example Vercel, Neon), and developer workstations.

A.3 Security architecture

Authentication

• Multi-factor: TOTP-based MFA available for users via the SaaS authentication flows.
• Session tokens: Cryptographically signed with production secret-strength checks.
• Session management: 24-hour access sessions and 7-day refresh sessions with revocation controls.
• Password policy: Minimum 12 characters; complexity requirements enforced server-side.
• Brute-force protection: Rate limiting and configurable account lockout controls.

Authorization (RBAC)

• Role-based access control with roles including owner, admin, finance_manager, project_manager, engineer, field_tech, viewer, auditor.
• Per-route permission checks via RBAC middleware.
• Platform admin operations require a separate platform administrator key.

Data protection

• Encryption at rest: Sensitive PII encrypted with AES-256-GCM in the application layer.
• Encryption in transit: TLS for database connections and HTTPS for client and API traffic.
• Parameterized queries: SQL uses parameterized statements to reduce injection risk.
• Input validation: Validated payloads on write endpoints.

Network security

• Tiered rate limiting (authentication, API, SCADA, admin, upload, global).
• CORS restricted to approved origins.
• HTTP security headers (for example Helmet: CSP, HSTS, frame protections) in production configurations.

Secrets management

• Secrets loaded from environment variables; production fails fast if required secrets are missing.
• No hardcoded production secrets in source; CI includes secret scanning.

A.4 Governance & risk management

Information security risks are identified through architecture review, dependency and vulnerability monitoring, incident and audit findings, and periodic policy review. Mitigations include technical controls above, patch SLAs, access reviews, and least-privilege provisioning. Residual risk is monitored via logging, metrics, and management review on at least an annual cycle or when material changes occur.

A.5 Third-party and financial integrations

Integrations (for example payment processors and bank-linking partners) are configured with scoped credentials, least-privilege API usage, and encryption in transit. Subprocessors are assessed against this policy and customer DPAs where applicable.

A.6 Vulnerability management

• Dependencies scanned in CI (for example npm audit).
• GitHub Dependabot for dependency updates.
• Target patch windows: Critical — 24h, High — 7d, Medium — 30d (subject to risk and compatibility).

A.7 Logging & monitoring

• Structured logging with PII redaction where applicable.
• Audit trail for state-changing operations.
• Operational metrics and internal health endpoints as configured per environment.
• Process-level handlers for uncaught exceptions and unhandled rejections.

A.8 Acceptable use

• Platform credentials must not be shared.
• Integration credentials are reviewed and rotated based on provider capability and risk.
• Debug endpoints disabled in production.
• Developer bypasses prohibited in production builds.

A.9 Compliance alignment (reference)

B.1 Purpose

Define rules for granting, reviewing, and revoking access to the Flux Energy platform to enforce least-privilege principles.

B.2 Role definitions

B.3 Access provisioning

New users

1. Tenant admin creates the user through tenant administration APIs.
2. Minimum required role is assigned (least privilege).
3. User receives invitation with temporary credentials where applicable.
4. User must set password and may enable MFA on first login.

Role changes

1. Requested by the user’s manager (or equivalent).
2. Approved by tenant admin.
3. Change logged in the audit trail.
4. Previous role permissions revoked immediately.

Elevated access

• Platform admin access requires a separate platform key from end-user credentials.
• Super-admin operations are rate-limited and audited.
• Temporary elevated access expires automatically (for example within 8 hours).

B.4 Access review

B.5 Access revocation

Triggers

• Employee termination or role change
• Security incident involving the user
• Extended inactivity (90+ days)
• Failed access review

Process

1. Disable user account (inactive).
2. Revoke active sessions / tokens.
3. Remove from role assignments.
4. Log revocation in the audit trail.
5. Review recent activity for anomalies.

B.6 Technical controls

B.7 Multi-tenant isolation

• Every request runs under its tenant context; Postgres row-level security (FORCE RLS) enforces isolation at the database.
• Isolation is verified by a weekly two-tenant sweep and an hourly runtime-posture check; the current status of the database-role control is recorded in our security finding log.
• Platform admin actions are logged separately and monitored for anomalies.

C.1 Purpose

Define how long each data category is retained, when and how it is archived or destroyed, and the legal or regulatory bases for retention periods.

C.2 Scope

All data stored in the Flux Energy platform: PostgreSQL databases, file storage, backups, logs, and third-party integrations.

C.3 Retention schedule

C.4 Archival process

1. Automated: Historical SCADA data may be moved to archive storage when older than the configured threshold.
2. Financial close: GL periods locked; archived data becomes read-only.
3. Backup rotation: Database backups retained per schedule; point-in-time recovery within the backup window where enabled.

C.5 Disposal methods

C.6 Litigation hold

When a litigation hold is active, affected data is exempt from routine disposal until the hold is formally released.

C.7 Compliance verification

• Periodic review of data against retention thresholds
• Annual review of disposal logs versus retention schedule
• Backup integrity validated per disaster-recovery testing cadence

C.8 Exceptions

Exceptions require written approval from the Compliance Officer and Legal Counsel. Exceptions are logged in the audit trail.