Compliance by Design

Version: 1.0
Date: September 8, 2025\

Objective: To build compliance and enterprise-grade trust into the core architecture of the ChainAlight platform.
Philosophy: Compliance is a product feature, not an afterthought. By providing built-in, automated compliance controls, we transform ChainAlight from a software tool into a strategic risk management investment for our customers.

These requirements form the foundation for all specific compliance controls.

Role-Based Access Control (RBAC): The system must have a granular RBAC system, allowing customer administrators to define roles with specific permissions (e.g., view, edit, approve, export) for different modules and data sets.
Multi-Tenant Data Isolation: The architecture must enforce strict data isolation between customer tenants at the database (schema-per-tenant), application, and network levels.
Encryption: All data must be encrypted in transit (using TLS 1.2+) and at rest (using AES-256), with support for customer-managed encryption keys (BYOK) for enterprise customers.
Immutable Audit Logging: A central, immutable audit service will log all critical system and user events, including user logins, data access, plan modifications, and administrative changes.

a. Core Principle: To ensure the integrity, auditability, and executive accountability of financial planning data that could impact a public company's financial reporting.
b. Specific Functional Requirements:
1. Immutable Audit Trail for Financial Data: Every change to a locked financial plan or its core inputs (e.g., Forecast_Units, Revenue_Forecast, COGS) must be logged. The log must contain the user, timestamp, old value, new value, and the business justification entered by the user during the change.
2. Segregation of Duties (SoD) Workflow:
  - The system must have a configurable workflow engine.
  - An administrator must be able to create rules such as: "A user with a 'Planner' role cannot approve a plan they have edited. Approval requires a user with a 'Manager' role".
3. Plan Versioning & Change Management: The "Consensus Lock-In Protocol" must create a unique, versioned snapshot of the plan (e.g., 2025-09.EXEC.03). The system must provide a "delta view" to compare any two versions and an auditable rollback capability.
4. Data Retention: The Admin Backend must have a data retention policy engine. A customer admin can set a policy (e.g., "7-year retention for all locked S&OP cycles"), and the system will automatically archive and, after the period, securely delete the data to meet SOX requirements.

a. Core Principle: To demonstrate a high level of trust in how we handle customer data across the five Trust Services Criteria, with a focus on Security, Availability, and Processing Integrity.
b. Specific Functional Requirements:
1. Security:
  - Multi-Factor Authentication (MFA): MFA must be an available and enforceable option for all users.
  - Vulnerability Management: Regular, automated security scanning and a formal process for third-party penetration testing must be in place.
2. Availability:
  - High Availability Architecture: The system must be deployed across multiple availability zones with automated failover capabilities to support a 99.9% uptime SLA.
    - Disaster Recovery: The system must have automated, point-in-time recovery for databases and a documented disaster recovery plan with a target Recovery Time Objective (RTO) of <4 hours. 3. Processing Integrity:
  - Automated Reconciliation: The Intelligent Data Ingestion Engine must perform automated checks to reconcile data between source systems and the ChainAlight operational store, logging all discrepancies for review.
  - Mathematical Integrity Checks: The "Five Section Intelligence Engine" itself is a core processing integrity control, ensuring the S&OP plan is always mathematically sound.

a. Core Principle: To protect the personal data of individuals (employees, customers, suppliers) and uphold their privacy rights by design and by default.
b. Specific Functional Requirements:
1. "Privacy by Design" Principles:
  - Data Minimization: The Intelligent Data Ingestion Engine must be configurable to only ingest fields necessary for the S&OP process. For example, it will ingest Sales Rep ID but not Sales Rep Home Address.
  - Purpose Limitation: The purpose for processing any personal data (e.g., employee names in decision logs) will be clearly documented.
2. Data Subject Request (DSR) Automation: The Admin Backend must provide a secure module for a customer's data protection officer to handle DSRs.
  - "Forget User" Functionality: A workflow that finds and securely deletes a user's personal data (e.g., their name from all Decision_Log entries and audit trails) from all systems, including a verification step.
  - Data Export: A function to export all personal data associated with a user in a portable, machine-readable format (e.g., JSON).
3. Record of Processing Activities (RoPA): The Admin Backend will feature an auto-generated report that documents all personal data fields being processed, their source, their purpose, and their retention schedule, as required by GDPR Article 30.