Compliance
How Aorka's technical controls map to HIPAA, SOC 2, NIST CSF, and FINRA. This is not a certification claim — it is a transparent mapping of what we have built and which compliance requirements it satisfies. Audit status is in the Roadmap section at the end.
The HIPAA Security Rule (45 CFR Part 164, Subpart C) defines technical safeguards for protecting electronic protected health information (ePHI). Aorka does not store ePHI directly, but as a tool with execution access to systems that may contain ePHI, these controls are directly relevant.
| Requirement | Aorka implementation |
|---|---|
| Access Control 164.312(a)(1) | Role-based access control (admin, tenant_admin, tech, viewer, provisioning). Unit-scoped permissions with inheritance. Multi-tenant isolation — each organization is structurally separated at the database level. New units start read-only by default. Personal workspaces with ownership-based isolation. |
| Unique User ID 164.312(a)(2)(i) | Azure AD SSO with per-user identity. Every action is attributed to a specific authenticated user. No shared accounts — tenant auto-discovery assigns users to their organization automatically. |
| Emergency Access 164.312(a)(2)(ii) | Credential vault break-glass access with MFA verification, full audit logging, and webhook alerts. MFA backup codes for account recovery. Admin session management with remote revocation. |
| Automatic Logoff 164.312(a)(2)(iii) | Session expiration with configurable timeout. Session heartbeat monitoring. Active session listing with ability to terminate any session remotely. |
| Audit Controls 164.312(b) | Comprehensive audit log covering authentication events, job execution, script approvals and rejections, credential access, endpoint registration, configuration changes, MFA events, and administrative actions. Every entry includes user identity, timestamp, action type, and target resource. |
| Integrity Controls 164.312(c)(1) | HMAC‑SHA256 job signing — every command is cryptographically signed at creation and verified at dispatch. RSA‑2048 signed agent updates with trusted hash registry. Credential vault uses AES‑256‑GCM authenticated encryption (tamper detection built in). |
| Authentication 164.312(d) | Azure AD SSO (multi-tenant). TOTP-based MFA for sensitive operations. Device fingerprinting for agents. Mutual server authentication via HMAC challenge-response. Rate limiting on authentication endpoints. |
| Transmission Security 164.312(e)(1) | TLS 1.2+ on all connections (HTTPS for API, WSS for agent WebSocket). Mutual server authentication adds a second verification layer beyond TLS. Agents use outbound-only connections — no inbound ports or listening services. HSTS headers enforced. Let's Encrypt certificates with auto-renewal. |
SOC 2 evaluates controls across five Trust Service Criteria. The mappings below cover Security (Common Criteria) and Availability, which are the most relevant to an infrastructure management platform.
| Criterion | Aorka implementation |
|---|---|
| Logical Access CC6.1 | Five-tier RBAC with unit-scoped inheritance. Tenant isolation at the database layer. New users from unknown tenants receive a “provisioning” role (no access) until explicitly approved by a tenant admin. Unit read-only locks prevent write operations until explicitly enabled. |
| Authentication CC6.2 | Azure AD SSO with multi-tenant auto-discovery. TOTP MFA with backup codes. Session management: active session listing, remote revocation, security info dashboard. API authentication via signed tokens. Agent authentication via machine-bound encrypted credentials with device fingerprint binding. |
| Authorized Access CC6.3 | User-unit access grants with read/write distinction. Write access enables script execution up to score 50. Read access limits to diagnostic scripts (score 0–10). Credential access requires separate MFA verification. MCP tokens are IP-bound with MFA-protected rebinding. |
| System Boundaries CC6.6 | Agents initiate outbound WebSocket connections only — no inbound ports, no listening services, no VPN requirements. Three-layer script safety pipeline gates all execution: deterministic regex filter, AI risk scoring, and human approval. Hard ceiling at score 51 with no override. |
| Monitoring CC7.1 / CC7.2 | Audit log captures all security-relevant events with user attribution. Anomaly detection on fact values using Welford's algorithm for running variance. AlertService with configurable severity thresholds, in-app notifications, webhook delivery, and email alerts. |
| Change Management CC8.1 | Agent updates are RSA‑2048 signed with an offline private key. Trusted hash registry verifies agent versions on connection. Pull-based update model — agents decide whether to apply. Staged rollouts to test endpoints before fleet-wide deployment. |
| Risk Mitigation CC9.1 | Script safety pipeline with deterministic floor (regex) and hard ceiling (score 51+ blocked, no admin override). Script reliability scoring based on real execution history. AI risk evaluation independent of the chat model. HMAC job signing prevents job tampering between API and dispatch layers. |
The NIST CSF organizes cybersecurity controls into six functions. The mappings below reference both CSF 2.0 categories and the corresponding NIST 800‑53 control families.
Identify.
Protect.
Detect.
Respond.
Recover.
FINRA Rule 4370 (Business Continuity Plans) and SEC Regulation S-P (Safeguards Rule) require broker-dealers to protect customer information and maintain operational resilience. FINRA's cybersecurity guidance emphasizes access controls, data loss prevention, and vendor management — all areas where Aorka provides technical controls.
| Requirement | Aorka implementation |
|---|---|
| Access controls FINRA Cybersecurity Checklist | Role-based access with five tiers and unit-scoped permissions. MFA on sensitive operations. Azure AD SSO — no local password management. Session monitoring with remote revocation. Provisioning role quarantines new users until explicit approval. |
| Data loss prevention Reg S-P Safeguards Rule | Tenant isolation prevents cross-organization data access. AI requests are stateless — no customer data retained by AI providers. AES‑256‑GCM credential encryption. Audit logging on all data access events. Hard script execution ceiling prevents bulk data exfiltration commands. |
| Vendor management FINRA Rule 3110 | This compliance mapping provides transparency into Aorka's technical controls. Comprehensive audit logging enables oversight of all vendor-executed operations. Human approval gates ensure no automated action runs without explicit authorization. Webhook alerts notify your team of security-relevant events in real time. |
| Supervision & audit trail FINRA Rules 3110, 3120 | Every action is attributed to a specific authenticated user. Full job history with command text, approval chain, execution output, and timestamps. Conversation logs preserve the complete context of AI-assisted decisions. Audit data is retained and queryable for examination and regulatory review. |
| Business continuity FINRA Rule 4370 | Knowledge base preserves infrastructure state for disaster recovery reference. Orchestration engine enables automated multi-step recovery procedures. Outbound-only agent architecture means no firewall reconfiguration during failover. AWS RDS with automated backups for platform data continuity. |
Compliance is a continuous process. These are areas under active development.
We will walk through the controls with your compliance team and answer any questions. If you need a one-pager extracted from this document for a specific framework, ask — we can produce one.
Request a compliance walkthrough