Security Controls
Implemented security program — encryption, access enforcement, audit logging, and testing posture.
Encryption
Data in transit is encrypted using TLS 1.2 or higher at all service boundaries. All customer-facing endpoints are served exclusively over HTTPS. Unencrypted HTTP access is not permitted.
Data at rest is encrypted using AES-256 via the Supabase infrastructure provider. Encryption at rest applies to all stored customer data, audit logs, and governance records. Key management is handled by the infrastructure provider.
_Last reviewed: February 2026. Evidence: Available under NDA (architecture-diagram)._
Access Controls
Role-based access control (RBAC) is enforced at the application layer. Every API action is validated against the authenticated user's assigned role permissions stored in the org_role_permissions table. Permission checks are structural — unauthorized requests are rejected at the API boundary before any data operation is attempted.
Row-level security (RLS) is enforced at the database layer. All customer data tables have RLS policies enabled. Data is scoped to the authenticated organization. Cross-tenant data access is structurally prevented at the database layer, independent of application-layer controls.
Multi-factor authentication is supported through the Supabase authentication provider and is configurable by institution administrators.
Privileged administrative access to production systems is restricted to named personnel and reviewed on a defined schedule. Access removal is documented.
_Last reviewed: February 2026. Evidence: Available under NDA (rbac-rls-evidence-summary, tenant-isolation-authorization-model, privileged-access-review-cadence)._
Audit Logging
An immutable, append-only audit log is maintained for all governance events. Events recorded include: deal stage transitions, policy executions, authority checks, approval actions, exception requests and resolutions, AI output reviews, and user access events.
Every audit record captures: actor identity, organization, timestamp, action, outcome, and subject. The audit log cannot be modified or deleted by application-layer users.
Audit records are accessible to institution administrators via the platform audit interface. Export is supported for examiner review.
_Last reviewed: February 2026. Evidence: Available under NDA (audit-log-sample-retention-summary)._
Vulnerability Management
Dependency and static analysis scans run on each release pipeline. Critical and high findings are assigned remediation SLAs. Known vulnerabilities in production dependencies are tracked and remediated on the schedule below.
A formal vulnerability management policy governs identification, classification, remediation, and verification. Responsible disclosure is supported.
| Severity | Remediation Target |
|---|---|
| Critical | 7 days |
| High | 30 days |
| Medium | 90 days |
| Low | Risk-based backlog |
_Last reviewed: February 2026. Evidence: Available under NDA (vulnerability-management-policy, latest-scan-excerpt)._
Penetration Testing
A third-party application penetration test is scheduled for Q3 2026. No completed external penetration test artifact exists at this time. This status is reported accurately and will be updated when a completed test artifact exists. Results will be published under NDA upon completion.
_Status: Scheduled. Evidence: Not yet published (pentest-status)._
Incident Response
A formal incident response plan is in place covering detection, triage, severity classification, containment, customer notification, and post-incident review.
Confirmed incidents affecting Customer Data: CreditAxis will notify affected customers within 72 hours. Notification includes incident summary, scope assessment, and mitigation actions taken.
| Severity | Description |
|---|---|
| Sev 1 | Critical service outage or material security event |
| Sev 2 | Significant degradation or contained security event |
| Sev 3 | Moderate issue with available workaround |
| Sev 4 | Minor issue — low-impact |
_Last reviewed: February 2026. Evidence: Available under NDA (incident-response-plan)._
Compliance Framework
CreditAxis operates its security program aligned to NIST CSF 2.0 (Govern, Identify, Protect, Detect, Respond, Recover).
SOC 2 Type I readiness activities are underway. A formal Type I audit engagement is targeted for 2027. CreditAxis is a software vendor, not a covered financial institution — GLBA obligations apply to the customer institution.
| Framework | Status | Note |
|---|---|---|
| NIST CSF 2.0 | Adopted | Operating security framework |
| SOC 2 Type I | In Preparation | Type I audit targeted 2027 |
| SOC 2 Type II | On Roadmap | Post Type I |
| GLBA | Not Applicable | Applies to customer institution |
Subprocessors
CreditAxis engages three third-party subprocessors. The full inventory is published on the Vendor Risk page and in the Vendor Review Room.
- Supabase — Database hosting and authentication (SOC 2 Type II certified)
- Vercel — Frontend hosting and CDN (SOC 2 Type II certified)
- Hugging Face — AI/ML inference, conditional on Intelligence module activation
_Evidence: subprocessor-inventory (public)._
Planned Controls
The following controls are on the roadmap and not yet implemented:
- Formal SOC 2 Type I examination (targeted 2027)
- Third-party penetration test (targeted Q3 2026)
- Automated restore testing cadence (targeted Q3 2026)