Skip to security information

How does Arc protect our data?

Choose where Arc runs and which AI providers can process your data. Access controls and an exportable history keep engineering decisions traceable.

Where can Arc run?

Managed cloud. Arc operates a shared application and managed database with logical tenant isolation and supported regional data-residency options. This suits teams that want managed operations. Arc handles service authentication, backups, monitoring and releases; your team controls users and roles. Access uses TLS, AI runs through an approved provider or customer endpoint, and Arc administrative access is restricted to authorised service operations.

Your infrastructure. Run the application and database inside your own environment. Your team owns identities, access policy, network controls, monitoring and backups, and chooses approved AI endpoints or local models. External AI is optional. Releases follow a coordinated process, and Arc has no administrative access unless you grant it for support.

An isolated network. For disconnected or tightly restricted programmes, Arc can run without required external calls. Your team hosts the application and database, owns identities, access, monitoring and backups, and keeps inference local or self-hosted. Updates follow an offline process, with no standing Arc access.

Your own database. Keep programme records in a customer-owned database with any supported application model. Your team operates and backs up the database; application hosting, authentication, AI and releases follow the chosen deployment model. Connectivity is agreed for your architecture, and Arc has no database access unless you explicitly grant it.

Who controls the AI?

Choose approved models and processing locations. Arc’s read-only and drafting agents work within configured permissions; engineers review and approve controlled changes.

Arc and enabled model providers never use customer programme content to train models. Inference produces a requested result without training on it. Provider retention follows approved terms and configuration, so no training does not mean zero retention. Prompts, outputs and engineering changes retained in Arc follow your access and retention policy.

Embeddings and retrieval indexes are isolated to your organisation and its selected deployment boundary. You can connect approved model endpoints or credentials instead of using an Arc-selected provider. Administrators can identify the active provider, model and processing boundary.

On-premises and air-gapped deployments can keep inference local and disable external AI processing. See the AI governance details.

How is our data protected?

  • AES-256 protects stored programme data.
  • TLS 1.2 or later protects data moving between authorised systems.
  • Logical controls separate organisations in the multi-tenant service.
  • Roles govern viewing, editing, reviewing, approving and administration.
  • Access, changes, approvals and AI actions can be exported for review, alongside the attributable change history created through branch, review and merge workflows.
  • Regional residency options keep managed data in an agreed supported region.

Arc’s guided import maps existing requirements, fields, links and evidence into connected records for review. Review the source mapping and imported records before switching the authoritative record. See the migration details.

Which standards can we work with?

Arc connects requirements, baselines, reviews and verification evidence for your chosen process. Your standards, contracts, licences and assurance plan determine how Arc is configured and what evidence you need. Using Arc does not establish certification or regulatory compliance.

Can Arc support ECSS engineering work?

Arc supports project-tailored requirements, bidirectional traceability, baselines, controlled changes, review decisions and verification evidence used with ECSS-E-ST-10, ECSS-E-ST-10-06, ECSS-E-ST-10-02, ECSS-M-ST-10-01 and ECSS-M-ST-40. Alignment to an ECSS workflow is not ESA approval.

ECSS-E-ST-10C Rev.1 , ECSS-E-ST-10-06C , ECSS-E-ST-10-02C Rev.1 , ECSS-M-ST-10-01C , ECSS-M-ST-40C Rev.1

Can Arc hold space-system security records?

Arc can hold security requirements, ownership, information markings, change history and verification evidence used in a tailored ECSS-E-ST-80C process. Programme accreditation and any classified-information controls remain outside the product claim.

ECSS-E-ST-80C

Can Arc support NASA project requirements?

Arc supports requirements, configuration and data management, technical reviews, traceability, verification and validation records associated with NASA systems engineering practice. NASA requirements apply to suppliers when they are flowed down through the relevant contract; Arc is not NASA approved or certified.

NPR 7123.1D, Change 2 , NASA Systems Engineering Handbook

Can Arc help with UK spaceflight security?

Arc can organise cyber-risk assessments, mitigations and linked evidence for a spaceflight licensee’s security strategy. CAA CAP2535 provides strategy guidance for Space Industry Act licence applicants and licensees. The UK Space Agency toolkit provides additional guidance; responsibility remains with the licensee.

CAA CAP2535 v2.1 , UKSA Cyber Security Toolkit

Can Arc hold satellite cybersecurity evidence?

NIST IR 8441 applies the Cybersecurity Framework to hybrid satellite networks, with particular attention to interfaces between independently operated systems. Arc can organise requirements, ownership, mitigations and evidence for a customer-defined assessment. The profile is not a product certification.

NIST IR 8441

Can Arc be used with controlled information?

Assess customer-controlled deployments against the requirements and revision specified by the applicable contract. NIST SP 800-171 Rev. 3 is the current NIST publication; CMMC Level 2 currently references the 110 Rev. 2 requirements. Suitability depends on the complete configured environment and contractual flow-down. Arc’s multi-tenant SaaS is not automatically suitable for CUI.

CMMC requirements , NIST SP 800-171 Rev. 3 , DFARS 252.204-7012

Who is responsible for what?

Arc provides the product and agreed services. Your team owns programme classification, access and assurance decisions. Agree who operates each part of the deployment before adding programme information.

Arc delivers documented controls for your deployment, operates the agreed managed components, makes access, change, approval and AI-action history available for export, and explains the configured model providers and processing boundaries.

Your team classifies information, selects the deployment, assigns users, roles, reviewers and approval authority, and configures retention and evidence workflows. Your team also assesses the complete environment against applicable contracts, licences and standards.

Want to talk through your setup?

Bring your data, hosting and AI requirements. We’ll map the deployment and responsibilities together before you add programme information. You can also explore Arc’s engineering workflow or use the software comparison method to plan an evaluation.

Sources reviewed .