Compliance Readiness Statement

This page describes FactoryThread's current security and compliance readiness posture. It is not a certification statement. FactoryThread does not currently hold SOC 2 Type II, ISO/IEC 27001, 21 CFR Part 11, or GxP certifications.

FactoryThread is a data virtualization platform and is not designed to be a system of record for customer business data. The platform processes customer data during flow execution and retains limited operational metadata needed to operate, troubleshoot, and secure the service. Two limited cases where customer-derived data may be retained — bounded samples of failing input records on the error path, and ephemeral worker-side staging during a single run — are documented explicitly because they are part of the security and compliance boundary. See the Security Overview for the full statement.

Many of FactoryThread's underlying providers — Auth0 (identity), Microsoft Azure (compute, networking, managed Postgres, RabbitMQ), Stripe (billing), and OpenAI / LangChain (AI nodes, opt-in only) — already hold relevant independent certifications. Our work is to certify the FactoryThread layer that sits on top of those providers.

The compliance roadmap focuses first on SOC 2, followed by ISO/IEC 27001 based on customer demand. Regulated workloads such as 21 CFR Part 11 and GxP are addressed through deployment-specific customer validation, typically in on-prem or customer-controlled environments.

For each framework below we describe: applicability, current alignment, gap to certify, and target audit timeline.

SOC 2 Type II

Scope. SOC 2 is the most natural primary framework for FactoryThread: we are a SaaS platform that processes (rather than stores) customer data, and the Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and (where applicable) Privacy — map directly to how the platform is built and operated.

Stance. Meaningful readiness alignment with the SOC 2 Common Criteria. Formal evidence collection and auditor validation are not yet complete; we have not been audited.

Current alignment with the SOC 2 Common Criteria.

Criterion	What we have today
CC1 — Control environment	Defined engineering, security, and on-call ownership; corporate device management with SSO and MFA.
CC2 — Communication and information	Public security documentation (this site), customer support channels, internal runbooks.
CC3 — Risk assessment	Known-gap register published in our Security Overview with target quarters; recurring review.
CC4 — Monitoring activities	Structured logging, Grafana Alloy → Loki / Prometheus, dashboards for request rates, error rates, latency, and queue depth.
CC5 — Control activities	Auth0 OIDC + JWKS-verified JWTs, tenant-scoped row-level isolation, SHA-256-hashed API keys, mandatory PR review on the main branch, infrastructure as code.
CC6 — Logical and physical access	Physical access inherited from Microsoft Azure data-center controls; logical access via Auth0 + workspace scoping; production access limited to approved engineering personnel using SSO with MFA, least-privilege role assignments, and logged sensitive actions.
CC7 — System operations	Dependabot, `pnpm audit` in CI, type-checked builds, automated container deployment via GitHub Actions, separate develop / main branches.
CC8 — Change management	All production changes ship through PRs reviewed before merge; infrastructure-as-code tracks infra changes.
CC9 — Risk mitigation	Disaster recovery via Azure-managed PostgreSQL backups with point-in-time recovery; vendor risk register tracking Auth0, Azure, Stripe, and OpenAI.

Operational details security reviewers typically ask about.

Area	Current state
Access reviews	Production-access list reviewed periodically by engineering leadership. Cadence to be formalized as part of SOC 2 evidence collection.
Production access	Auth0 SSO with MFA enforced; role-based GitHub and Azure entitlements; sensitive admin actions logged. Break-glass and approval workflow to be formalized.
Vulnerability management	Dependabot and `pnpm audit` in CI on every PR; remediation tracked through standard PR review. SCA and image scanning to be formalized with severity-based remediation SLAs.
Backup / restore	Automated backups with point-in-time recovery via Azure-managed PostgreSQL. Restore-testing cadence to be formalized.
Incident response	Internal incident playbook with severity levels and customer notification process; response and notification SLAs to be published as part of the customer support agreement.
Audit logs	Today: publish events, API key lifecycle, execution insights, and infrastructure logs. Roadmap (Q3 2026): comprehensive in-product activity log.
Data retention	Execution insights retention is configurable per organization. Logs and failure-sample retention controls are on the roadmap.
Subprocessors	Auth0, Microsoft Azure, Stripe, and OpenAI / LangChain (the last only when a customer enables AI nodes). Subprocessor list and DPA available on request.

Gap to certify.

Formal evidence collection (control mapping, sample tests, exception tracking).
Engagement of a SOC 2 auditor and a Type I attestation prior to the Type II observation window.
Two items also on our public roadmap will land before the Type II observation window: connection-metadata encryption (Q2 2026) and a tenant-scoped activity audit log (Q3 2026). We do not currently expect either to prevent Type I readiness, subject to auditor scoping and testing.

Target. Scoping engagement and Type I attestation within 12 months. SOC 2 Type II observation window beginning thereafter; report available in 18-24 months from today.

ISO/IEC 27001

Scope. ISO/IEC 27001 (with the supporting ISO/IEC 27002 implementation guidance) is the international counterpart to SOC 2. Customers in EU and APAC markets often prefer ISO; many large enterprises require both.

Stance. Meaningful readiness alignment with the ISO/IEC 27001:2022 Annex A themes. We have not yet established a formal Information Security Management System (ISMS) or engaged a certification body.

Current alignment with ISO/IEC 27001:2022 Annex A themes. The 2022 revision reorganized Annex A into 93 controls across four themes:

Theme	FactoryThread alignment today
Organizational controls (37 controls)	Security ownership and on-call roles defined; vendor risk register tracking Auth0, Azure, Stripe, and OpenAI; public security documentation (this site); internal incident playbook; roadmap-based gap tracking.
People controls (8 controls)	Corporate SSO with MFA; defined onboarding and offboarding; role-based production access with periodic review; background checks where law permits.
Physical controls (14 controls)	Inherited from Microsoft Azure data-center controls in SaaS deployments; the customer's responsibility in on-prem deployments.
Technological controls (34 controls)	Auth0 OIDC with JWKS-verified JWTs and audience / issuer enforcement; tenant-scoped row-level isolation; SHA-256-hashed API keys; TLS 1.2+ in transit; Azure-managed encryption at rest with application-layer encryption for connection credentials shipping Q2 2026; structured logging into Loki / Prometheus; Dependabot + CI security checks; infrastructure as code.

Gap to certify. Formal ISMS scope documentation, risk-assessment methodology, Statement of Applicability, internal audit program, management review cadence, evidence collection, corrective-action tracking, and engagement of an accredited certification body.

Target. 18-24 months. We will pursue ISO 27001 in parallel with or shortly after the SOC 2 Type II report, depending on customer demand.

21 CFR Part 11 (US FDA — Electronic Records and Signatures)

Applicability is conditional. 21 CFR Part 11 applies when a regulated customer uses FactoryThread to create, modify, or sign electronic records that the FDA expects to inspect. For most non-regulated customers it does not apply; for regulated customers (pharma, medical-device, biotech, food) it may, depending on the workload.

What we offer today that is relevant.

Strong identity (Auth0 OIDC, MFA, SAML federation) — supports unique-user-credential requirements.
Tenancy isolation in the database; per-workspace API keys with auditable creation timestamps.
Execution insights (run, status, duration, error context) and publish history (who published a given version, and when) — supports the audit-trail expectation.
Backups via Azure-managed Postgres — supports record-retention and recoverability.

Where we are not yet aligned.

Closed-system controls (per § 11.10) — we do not currently provide a fully closed system in SaaS mode; on-prem is the recommended posture for regulated workloads (see below).
Electronic-signature workflows (per § 11.50, § 11.70, § 11.100, § 11.200) — FactoryThread does not provide a built-in signing UI. Customers using FactoryThread to move records into a regulated system of record typically rely on the destination system for the signature controls.
Comprehensive audit trail covering every user action — today we capture publish events, API key lifecycle, and execution insights; the full activity log is on the Q3 2026 roadmap.

Recommended posture for 21 CFR Part 11 workloads. Deploy FactoryThread on-prem so the entire system operates inside the customer's qualified environment, under the customer's existing SOPs and validation. The on-prem release uses the same application code with reverse-proxy SSO; data and audit context never leave the customer network.

Important boundary. On-prem deployment can simplify the customer's validation effort because FactoryThread operates inside the customer's qualified environment. However, on-prem deployment alone does not make FactoryThread Part 11-compliant. Compliance depends on the customer's intended use, SOPs, validation package, audit trails, access controls, record-retention controls, and electronic-signature design. FactoryThread provides the application layer; the regulated customer owns the validation envelope around it.

Target. We will track customer demand. If a regulated customer commits to on-prem and asks for a Part 11 mapping for the FactoryThread application layer, we will produce that mapping document and align on what gaps the customer's IQ/OQ/PQ will need to cover. A formal Part 11 audit is not on the corporate roadmap today.

GxP (GMP / GLP / GCP)

Applicability is conditional, identical to Part 11. GxP refers to the broader family of "good practice" guidelines (Good Manufacturing, Good Laboratory, Good Clinical) — most of these reference Part 11 for electronic-record handling.

What we offer today. Same controls as listed under Part 11 above (identity, tenancy isolation, publish history, execution insights, backups).

Recommended posture. On-prem deployment. GxP workloads typically demand that data and the system that processes data both stay within a qualified, customer-controlled environment. The on-prem release is the right fit; data does not leave the customer network, and the customer's existing GxP SOPs and validation lifecycle (URS / FS / DS / IQ / OQ / PQ) wrap the FactoryThread containers.

Important boundary. As with Part 11, on-prem deployment alone does not make FactoryThread GxP-validated. GxP validation is owned by the customer and depends on the customer's intended use, SOPs, change-control procedures, training records, and qualification lifecycle.

What we will do for a GxP customer.

Provide a system architecture document tailored to the on-prem release (the Data Flow & Architecture Guide, available under NDA).
Provide a control-matrix mapping each GxP-relevant FactoryThread feature to the customer's validation expectation.
Lock the deployed FactoryThread version to a specific release tag for the customer's qualified environment.

Target. Demand-driven. We will not pursue an annex of GxP self-certification; the practical path is per-customer validation in the on-prem environment.

Shared responsibility by deployment model

FactoryThread's security and compliance responsibilities differ across the three deployment modes. The full breakdown is in our Shared Responsibility Matrix; a high-level summary:

Control area	SaaS	Single-tenant managed	On-prem
Application security	FactoryThread	FactoryThread	FactoryThread
Cloud / host infrastructure	FactoryThread + Azure	FactoryThread + Azure	Customer
Network controls	FactoryThread	FactoryThread	Customer
Identity provider	FactoryThread / Auth0 (or customer-federated via Auth0)	FactoryThread / Auth0 (or customer-federated)	Customer (reverse-proxy SSO)
Data residency	FactoryThread cloud region (default or contracted)	Customer-pinned region	Customer environment
Backup operations	FactoryThread	FactoryThread	Customer
GxP / Part 11 validation	Customer-led	Customer-led	Customer-led

This matters most for regulated workloads: even with FactoryThread aligned to SOC 2 / ISO 27001 readiness, the regulated customer remains responsible for their own GxP / Part 11 validation envelope.

Summary

Framework	Stance	Target
SOC 2 Type II	Meaningful readiness alignment with the Common Criteria; auditor not yet engaged	12-month scoping + Type I; Type II report in 18-24 months
ISO/IEC 27001:2022	Aligned with Annex A themes; no formal ISMS yet	18-24 months
21 CFR Part 11	Conditional applicability; on-prem recommended; customer owns validation envelope	Per-customer mapping on demand
GxP	Conditional applicability; on-prem recommended; customer owns validation envelope	Per-customer validation on demand
GDPR	Aligned with Processor obligations; DPA and subprocessor list on request	Available now

Contact

For the NDA-gated security packet, CAIQ-Lite or SIG-Lite, a DPA, or a 30-minute walkthrough with the FactoryThread security team, email support@factorythread.com.

SOC 2 Type II​

ISO/IEC 27001​

21 CFR Part 11 (US FDA — Electronic Records and Signatures)​

GxP (GMP / GLP / GCP)​

Shared responsibility by deployment model​

Other frameworks and questionnaires​

Summary​

Contact​