SOC 2 System Description

This document is the Description of the System required by the AICPA SSAE 18 Trust Services Criteria — the narrative auditors and report readers rely on to understand what Neuroscale’s services do, how they are built, who operates them, and where the boundaries of Neuroscale’s responsibility end and a customer’s or subservice organization’s begin. It is Section III of the eventual SOC 2 report, alongside Section I (Auditor’s Report), Section II (Management’s Assertion), and Section IV (Trust Services Criteria, Controls, and Tests).

​

1. Company overview

NEUROSCALE LLC (“Neuroscale”) is a Virginia limited liability company (registered office: 46175 Westlake Dr Ste 300, Sterling, VA 20165) operating an AI recruiting platform and related services. Neuroscale provides AI-assisted candidate sourcing, ranking, screening, and outreach for enterprise and U.S.-government recruiting workflows; the services in scope are enumerated in §2. Neuroscale’s current customers include enterprise commercial customers and U.S.-government agencies. (Specific agency names are omitted here because this description is distributed as part of the SOC 2 report; named-customer references are governed by the relevant contract confidentiality / publicity clauses.) Neuroscale does not currently hold a FedRAMP authorization; federal customers consume the commercial-cloud offering under contract clauses appropriate to the workload. The company is led by Ishan Jadhwani (CEO), with executive leadership comprising the CEO, CTO, CISO, CFO, General Counsel (who also acts as Privacy Officer), and CHRO. The full role-to-person mapping is maintained at /handbook/roles-personnel and reviewed quarterly.

​

2. Services in scope

The services in scope of this SOC 2 report are the Arbi recruiting platform and the supporting infrastructure that delivers it to customers. This includes:

• Arbi web application — multi-tenant, customer-facing web product through which Customer-employer users author requisitions, search and source candidates, run AI-assisted screening and ranking, send candidate outreach, and track candidates through their hiring pipeline.
• Arbi public API — REST and GraphQL endpoints that allow Customer-employer integrations to read and write Arbi data programmatically.
• AI features — AI-assisted candidate ranking, screening, summary, and outreach features that call upstream foundation-model providers (Anthropic, OpenAI, xAI, Cerebras via Portkey) under enterprise terms.
• Neuroscale Sourcing Database — Neuroscale-controlled, lawful-basis sourcing data used to surface candidate matches; governed by the Art. 14 Notice.
• Customer-data persistence — relational stores, object storage for resumes / documents / attachments, and the supporting backup-and-restore subsystems.
• Authentication, authorization, audit, and admin surfaces — the identity surface customer admins use to manage their own users and the audit log they consume.

Out of scope (explicitly excluded from this report):

• Neuroscale’s corporate IT environment except where it enforces controls on the services in scope (e.g., Rippling IdP, which gates workforce access to production).
• Pre-production environments (development, CI, staging) except for the segregation and data-handling controls that protect production from cross-contamination.
• Marketing, sales, and customer-success workflows that do not process Customer Personal Data submitted to the Arbi services.
• One-off professional-services or custom-engineering engagements outside the standard Arbi product.
• The Aurora and Athena product features named in the Terms of Service, which are delivered under separate governance regimes and are not part of the Arbi recruiting services attested in this report. (“Aurora” here refers to the product feature, distinct from the AWS Aurora database engine referenced in §5.)

​

3. Trust Services Criteria in scope

The initial Type II report (observation window June 22 – September 22, 2026) covers the Security criterion only. Availability, Confidentiality, and Privacy are scoped into the first subsequent Type II report (observation window September 22, 2026 – September 22, 2027); Processing Integrity is not in scope in any window. Why descope for the initial window. The initial Type II observation window is 3 months, opening only ~6.5 weeks after policy effective date (2026-05-08) and on the same day as Type I observation (2026-06-22). Management determined — and the ISMS Management Review ratified — that standing up the ~30–40 additional A/C/P control rows in time to produce 3 months of operating-effectiveness evidence in the initial window would add audit risk rather than reduce it. The subsequent 12-month window expands scope on a cadence the program can sustain with operating evidence. Section IV of the eventual report maps each in-scope criterion to one or more Neuroscale-side controls drawn from the Controls Inventory and tested by Advantage Partners.

​

4. System boundaries

The services in scope are delivered from Neuroscale-controlled infrastructure on two cloud providers — AWS (primary) and Vultr (secondary) — that together host the application, the data stores, the secrets surface, the logging surface, and the AI-feature plumbing. The system boundary is:

• Inside the boundary: the Arbi web application and API; the relational and object stores that hold Customer Content; the LLM gateway that routes AI-feature requests; the secrets-of-record (Vault) and key-management surfaces; the logging and monitoring path from production into the security-and-audit log retention store; the workforce-identity surface that gates production access (Rippling is the workforce IdP, federated into AWS IAM Identity Center and Cloudflare Access for human production access; Vault issues short-lived workload-to-workload credentials — see §5.1 and §5.2).
• Corporate office — limited physical-security scope: Neuroscale operates a single corporate office at 46175 Westlake Dr Ste 300, Sterling, VA 20165. No production systems or production data stores are hosted on-premises — all in-scope production infrastructure runs on AWS and Vultr (§5), whose data-center physical and environmental controls are carved out to those subservice organizations (§10.2). The office is within the system boundary only for the physical-security controls that protect workforce endpoints and Restricted internal information: entry controls (mechanical locks and Neuroscale-issued keys), CCTV at common-area entry points, visitor sign-in / escort, and the secure-area restrictions in the Physical Security Policy. These controls operate under the Security criterion (CC6.4).
• Outside the boundary, carved out: the third-party subservice organizations listed in §10, including AWS, Vultr, Rippling, Microsoft 365, Better Stack, the upstream AI providers, the LLM gateway operator (Portkey), and the ancillary data-enrichment and email-delivery providers. Their internal controls are not tested by Advantage Partners; reliance is via their own SOC 2 / ISO 27001 reports and contractual commitments (see §10).
• Outside the boundary, customer responsibility: Customer-employer internal IT, Customer-employer end-user devices, and Customer-employer integrations with third parties not contracted by Neuroscale (see §11 — Complementary User Entity Controls).
• Outside the boundary, carved out by design for independence: the GlobaLeaks anonymous-reporting platform, operated independently of Neuroscale management per the Whistleblower Policy and Audit Committee Deferral Memo 2026. The host is operated outside Neuroscale’s production environment and corporate identity perimeter, with access designed so that Neuroscale operational management (including the CTO and CISO) holds no administrative access. The platform is excluded from the system boundary to preserve reporter anonymity and its independence from operational management. Its operating runbook (patching, backup, key management, continuity-of-access) is maintained separately and reviewed at each ISMS Management Review.

​

5. Infrastructure

​

5.1 Cloud footprint

No EU-region or non-US production deployment exists at the time of this description; the Subprocessor List is updated before any cross-region rollout.

​

5.2 Network architecture

Production traffic terminates at Cloudflare (edge), passes through Cloudflare Access (identity-aware zero-trust gating for internal surfaces) and Cloudflare Gateway (egress filtering + DNS filtering), and is routed to the relevant AWS or Vultr ingress. Cross-cloud traffic between AWS and Vultr is over TLS 1.2-or-better. The corporate-side connection to production for engineering and operations is Tailscale (production-cohort only, gated quarterly per the Access Reviews procedure) for break-glass and bastion access; routine engineering work is via Cloudflare One + workload-bound identity.

​

5.3 Data stores

​

5.4 Cryptography surface

Application-layer envelope encryption is performed through HashiCorp Vault Transit with Neuroscale-managed keys configured as non-exportable; under that configuration, key material is designed to persist only within Vault’s encrypted barrier and its barrier-sealed snapshots (§5.3). Cloud-native at-rest encryption (AWS KMS, Vultr platform encryption) is layered beneath. The full key-class table is in the Cryptography Policy; operating procedure is the Key Rotation procedure.

​

6. Software components

The Arbi platform is composed of a small set of long-running services. The detailed service inventory — service names, owners, language/runtime, and inbound/outbound dependencies — is maintained in Engineering’s architecture-documentation repository and provided to the auditor on request. The system-level diagrams — Network Diagram, Data Flow Diagram, IAM Diagram, CI/CD Pipeline Diagram, and DR & Backup Diagram — are maintained in this repository. The narrative below summarizes by function rather than by service:

• Web frontend — customer-facing web UI (Vercel-hosted edge runtime + AWS-hosted API origin per the Subprocessor List).
• API gateway — request routing, authentication, and rate-limiting in front of the application services.
• Application services — business logic for requisitions, candidates, sourcing, ranking, outreach, and audit.
• Authentication and identity — customer-side authentication via WorkOS SSO + organization/membership management; workforce-side via Rippling IdP per Access Control Policy.
• LLM gateway — Portkey AI routes model traffic to upstream providers (Anthropic, OpenAI, xAI, Cerebras) under enterprise terms that prohibit training on Neuroscale-submitted inputs (see AI Acceptable Use Policy).
• Background workflows — Temporal Cloud for long-running and asynchronous orchestrations that may carry Customer Content.
• Transactional email — Resend for outbound transactional and notification email.
• Sourcing-data enrichment — People Data Labs, RocketReach (contact discovery), Kickbox (email-deliverability validation), NumVerify / APILayer (phone validation) for sourcing-side enrichment per the AI Training-Data Transparency Notice.
• OCR for submitted documents — AWS Textract for resume / document text extraction.
• Observability — Better Stack for logs / uptime / on-call paging; AWS CloudWatch as the cloud-native baseline.

Changes to these components flow through the Change Management procedure with Code Review and the Release Checklist gates.

​

7. People

​

7.1 Organizational structure and reporting lines

Neuroscale’s leadership comprises six Tier-1 executive roles — CEO, CTO, CISO, CFO, General Counsel, CHRO — with day-to-day operational responsibilities split across six Tier-2 roles — Engineering Lead, Engineering On-call, Security On-call, Incident Manager, System Owner, Data Owner. At the company’s current scale, several Tier-2 roles are filled by an executive (e.g., the CTO is also the System Owner for the Arbi platform; the CISO is also the Security On-call lead). The full mapping is in /handbook/roles-personnel and is reviewed quarterly. The in-scope workforce-control population comprises Neuroscale’s employees and contractors; the entity-level personnel controls — Code of Conduct acknowledgment, policy acknowledgment, security-awareness training, background screening, and endpoint/device controls — apply to all of them. Non-staff advisors hold no access to any in-scope system (no production, source-control, customer-data, secrets, or Confidential-data access) and are therefore outside the workforce-control population; they are maintained in a dedicated, access-excluded group in the workforce-identity system and are bound by executed confidentiality agreements. Should an advisor be granted access to any in-scope system, they enter the workforce-control population and are screened, acknowledge policies, and complete training before access is provisioned. The access-control criteria (CC6) apply per system to the subset of the workforce with access to that system; production and privileged-infrastructure access is held by a small subset. Actual population counts for each control are maintained in the tested rosters — the workforce roster in the identity / compliance system and the per-system access-review rosters — not in this narrative.

​

7.2 Separation of duties

Material separation-of-duties (SoD) controls in scope:

• Production-release approval. The release-prep PR author and the production-deploy approver are not the same person. The production-release GitHub Environment is configured with “Prevent self-review” so the prep-PR author cannot also approve the production deploy. See Change Management → Standard change procedure.
• Background-check adjudication. The hiring manager receives only the disposition; report content is restricted to the CHRO, People Operations support, and (where engaged) the General Counsel. See Background Checks procedure.
• Cryptographic-root operations. Vault root-token operations and Vault Transit key rotations require both CISO and CTO presence per the Key Rotation procedure.
• ISMS Management Review approval. Decisions are signed by the CISO and the General Counsel per the ISMS Management Review procedure.

​

7.3 Background screening, training, onboarding, offboarding

• Background screening is tiered (T1 / T2 / T3 / International) per Background Checks → Background-check tiers. Production-scope access is gated on a T2 clearance; the gate is operationalized in the Onboarding procedure.
• Security awareness training is required on hire and at least annually thereafter, delivered and tracked through Vanta per the Security Awareness Training procedure and the HR Security Policy.
• Offboarding revokes access on the tiered SLA in Access Control → Removal & adjustment and the Offboarding procedure.

​

8. Data

​

8.1 Classifications

Neuroscale uses a three-class scheme defined in the Data Management Policy: Per §3, Confidentiality and Privacy criteria are deferred to the first subsequent Type II window (Sep 22, 2026 – Sep 22, 2027); this column reflects the criteria the data class falls under once deferred criteria are in scope.

​

8.2 Data flow at the narrative level

1. Ingest. A Customer-employer user authenticates via WorkOS SSO and uploads or imports Customer Content into Arbi.
2. Persistence. Content is encrypted at the application layer (Vault Transit envelope wrap for fields classified Confidential) and persisted to the relational store (Aurora / Postgres) or object store (S3 / Vultr Object Storage) per its type.
3. AI features. When the customer-facing feature requires it, the relevant Customer Content (or a redacted derivative) is sent through the Portkey LLM gateway to an upstream model provider (Anthropic, OpenAI, xAI, Cerebras) under the enterprise terms described in §6.
4. Sourcing-data enrichment. Where the customer-facing feature requires it, identifiers may be sent to People Data Labs, RocketReach, Kickbox, or APILayer / NumVerify for the enrichment described in the Subprocessor List.
5. Observation. Application-level audit events flow to Better Stack and CloudWatch; security-and-audit-class events are archived to AWS S3 with Object Lock for 13-month minimum retention per Operations Security → Log retention tiers.
6. Egress. Outbound customer communications (notifications, candidate emails) flow through Resend.

​

8.3 Deidentification of training data

Where Customer Content is used to train, fine-tune, evaluate, or improve Neuroscale’s own AI models, the AI Acceptable Use Policy → Deidentification standard requires that it first be transformed into Deidentified Data — direct-identifier redaction, quasi-identifier generalization, statistical disclosure controls, sensitive-attribute removal, and a post-training re-identification audit, with the exact parameters specified in the policy. The policy prohibits training on raw Customer Content. These deidentification controls are part of the AI program and are attested when the Confidentiality and Privacy criteria come into scope in the first subsequent window (§3).

​

8.4 Retention and disposal

Retention by data class lives in the Records Retention Schedule. Disposal events are logged in the Disposal Log per the Records Disposal procedure.

​

8.5 Neuroscale Sourcing Database (controller-side data)

Distinct from Customer Content (where Neuroscale acts as processor), the Neuroscale Sourcing Database is a Neuroscale-controlled, lawful-basis pool of sourcing data used to surface candidate matches; for this data Neuroscale acts as controller and the processing is governed by the Art. 14 Notice and the Sourcing & Data Acquisition Policy. Its ingest, suppression-list, opt-out, and retention controls are operated under that policy and the Records Retention Schedule. Sourcing Database records are classified Confidential (§8.1) and fall within the Security criterion in scope for this report; the controller-side privacy controls layered on them are attested when the Privacy criterion comes into scope in the first subsequent window (§3). Where Sourcing Database records are used to train, fine-tune, or evaluate Neuroscale’s own AI models, they are first transformed into Deidentified Data under the same deidentification standard described in §8.3; the policy prohibits training on raw Sourcing Database records.

​

9. Procedures (control framework)

Section IV of the eventual report cites individual controls and their tests. The narrative-level control framework that operates the in-scope criteria is summarized below; the full mapping lives in the Controls Inventory. AI-specific controls are listed for completeness as part of Neuroscale’s broader control framework; they are attested as the Confidentiality and Privacy criteria come into scope in the first subsequent window (§3), not as Security-criterion controls tested in the initial window.

​

10. Subservice organizations and treatment

Neuroscale uses the carve-out method for subservice organizations: their internal controls are not tested under this report. Reliance is via their own SOC 2 / ISO 27001 / equivalent attestations on file with Neuroscale and via contractual commitments. The complementary controls that Neuroscale relies on each subservice organization to operate are listed in §10.2.

​

10.1 Subservice organizations

​

10.2 Complementary Subservice Organization Controls (CSOCs)

The subservice organizations above are responsible for the controls below. Where they fail, Neuroscale’s in-scope controls do not by themselves achieve the relevant Trust Services Criteria.

• AWS / Vultr — physical and environmental security of the data-center facilities, including physical access, environmental controls (HVAC, fire suppression, power), and infrastructure availability per the published SLAs.
• AWS / Vultr — cloud-native encryption services continue to operate (KMS / platform encryption) as documented; key material remains protected per the provider’s policies.
• Rippling — IdP and MDM availability sufficient to support workforce authentication and device-posture enforcement.
• Microsoft 365 — SharePoint availability and content integrity for the evidence library and the operational SOPs that depend on it.
• Better Stack — log ingestion and retention at the durability and availability the service publishes.
• Cloudflare — Cloudflare Access policy enforcement and TLS termination at the edge.
• AI providers (Anthropic, OpenAI, xAI, Cerebras) — data handling per the enterprise terms described in §6, including the contractual prohibition on training on Neuroscale-submitted inputs.
• Portkey AI — gateway-side handling of model traffic complies with the documented data-handling commitments.
• Checkr — FCRA / state-CRA compliance for the screens it operates on Neuroscale’s behalf, including the disclosure / authorization / adverse-action workflow.
• Vanta — compliance evidence platform availability, integration-test integrity, and acknowledgement / training record retention sufficient to support Neuroscale’s continuous-control monitoring and the evidence requests of SOC 2 / ISO 27001 fieldwork. Neuroscale’s controls assume Vanta integrations (IdP, cloud, SaaS) are reachable and that ack/training records are durable.
• Nylas / Unipile / OVH US — data handling per their executed DPAs for the outreach-feature mailbox and LinkedIn content and the candidate profile/avatar images they process on Neuroscale’s behalf, including the confidentiality, access-control, and breach-notification commitments in those agreements.
• All providers — incident notification to Neuroscale on a timeline that supports Neuroscale’s own customer-notice obligations.

​

11. Complementary User Entity Controls (CUECs)

Customers are responsible for the controls below. Where a customer fails to operate them, Neuroscale’s in-scope controls do not by themselves achieve the relevant Trust Services Criteria for that customer’s data.

• Customer-administered user accounts. Customer admins are responsible for creating, modifying, and deleting Customer-employer end-user accounts in the Arbi tenant they control, and for promptly removing access when a Customer-employer user changes role or leaves.
• Customer-side authentication configuration. Where a Customer-employer chooses to enforce SSO, MFA, or session controls beyond the Arbi defaults, the customer is responsible for configuring and maintaining those settings in their IdP and in the Arbi tenant settings.
• Customer-side credential handling. Customers are responsible for protecting their authentication credentials (passwords, SSO tokens, API keys) from disclosure, sharing, or compromise.
• Customer-side acceptable use. Customers are responsible for ensuring that the data uploaded to the Arbi services and the use of AI features comply with the Master Services Agreement, the Data Processing Addendum, and applicable law (including bias-audit obligations under NYC Local Law 144 where the Customer is the deployer of an AEDT).
• Customer-side human oversight of AI output. Customers are responsible for maintaining meaningful human review of AI-assisted ranking, screening, and summary output and for not using that output as the sole basis for a consequential employment decision, consistent with the Master Services Agreement, the AI Acceptable Use Policy, and applicable automated-employment-decision law.
• Customer-side outreach consent. Where a Customer directs candidate outreach (email or SMS) through the Arbi services, the Customer is responsible for any required consent, suppression-list maintenance, and compliance with applicable communications law (e.g., CAN-SPAM, TCPA, and state equivalents).
• Customer-side data handling. Customers are responsible for the lawful basis under which they upload candidate data, for delivering any required notice to candidates, and for honoring any opt-out the Customer’s own privacy notice describes.
• Customer-side incident reporting. Customers are responsible for promptly reporting suspected unauthorized access or use of their Arbi tenant to security@neuroscale.ai per the security-incident reporting clause of their Master Services Agreement.
• Customer-side review of Neuroscale’s notice updates. Customers are responsible for reviewing updates to the Privacy Notice, the Subprocessor List, and the Trust Center.
• Customer-side audit-log review. Where Arbi exposes a customer-visible audit log, customers are responsible for reviewing it for anomalous activity within their tenant.

​

12. Significant changes during the period

[Type I — N/A; the report is point-in-time.] [Type II — to be completed at Type II fieldwork. Significant changes during the relevant observation period will be enumerated here. The first observation period is the initial Type II window of June 22, 2026 – September 22, 2026 (three months); subsequent observation periods are the rolling 12-month windows (first subsequent: September 22, 2026 – September 22, 2027). Each report’s §12 covers material changes to in-scope services, in-scope infrastructure, in-scope subservice organizations, key personnel in roles material to the controls, and the addition or retirement of in-scope controls during that report’s window.]

​

13. Significant events during the period

[Type I — N/A.] [Type II — to be completed at each Type II fieldwork. Significant events during the relevant observation period (initial three-month window June 22 – September 22, 2026, or one of the subsequent rolling 12-month windows) will be enumerated here, including: any Severity 1 or Severity 2 incident per the Incident Response Policy, any incident triggering customer notice, any regulatory action, and any control failure that materially affected the in-scope criteria. Each event will reference the corresponding incident-record evidence retained per the Records Retention Schedule.]

​

14. Principal service commitments and system requirements

Principal service commitments are the commitments Neuroscale makes to customers regarding the in-scope services. For the initial Type II window (Security criterion only), the principal commitment attested is the security commitment — Neuroscale commits to maintaining controls designed to protect Customer Content against unauthorized access, use, and disclosure: the access-control, encryption, logging, change-management, vulnerability-management, and incident-response controls described in §§5–9. These commitments are established in the customer Master Services Agreement (MSA), the Data Processing Addendum (DPA), and the Trust Center. Availability, confidentiality, and privacy commitments — the uptime commitments in the SLA (operated as an operational target today, with the contractual service-credit regime effective 2026-09-22 per the SLA’s own effective date), the confidential treatment of Customer Content, and the privacy commitments in the Privacy Notice and DPA — are made to customers today but are attested beginning in the first subsequent Type II window, when the Availability, Confidentiality, and Privacy criteria come into scope per §3. System requirements are the policies and standards Neuroscale has established to meet those commitments — the framework inventoried in §9 and reconciled to the Controls Inventory. They include the access-control, cryptography, change-management, logging-and-monitoring, vulnerability-management, incident-response, and personnel-security requirements that the in-scope controls implement. The controls that operate these commitments and requirements are mapped to the in-scope Trust Services Criteria in Section IV of the eventual report.

​

15. Statement of management responsibility

Neuroscale management is responsible for:

• Designing, implementing, and operating the controls described in this report.
• Maintaining a system of internal controls designed to provide reasonable assurance that the in-scope criteria are achieved.
• Selecting the criteria in scope (§3).
• Identifying the risks that threaten the achievement of those criteria.
• Disclosing significant changes (§12) and significant events (§13) during the observation period.

The full Management’s Assertion is delivered as Section II of the eventual report and is signed by the CEO and CTO prior to fieldwork.

​

16. Cross-references

• Compliance Frameworks — the commitments overview page
• Compliance Calendar — milestone schedule for Type I and Type II
• SOC 2 Readiness Timeline — the working timeline through the Type II observation window
• Controls Inventory — the source-of-truth control list reconciled to Vanta
• Roles & Personnel — role-to-person mapping referenced from §1 and §7
• System diagrams — Network · Data Flow · IAM · CI/CD Pipeline · DR & Backup

​

Version history