Skip to security information
On this page

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. The standard Arc service runs on AWS in London, UK, with a shared application, managed database and logical tenant isolation. External AI and connected services may process information elsewhere. 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. Customer-hosted or on-premises operation is not part of the standard subscription. Availability, technical support and responsibility for authentication, access, AI, monitoring, backups and releases must be confirmed in separate signed deployment terms.

An isolated network. Air-gapped operation is not a standard subscription feature. A disconnected deployment, local inference and offline updates require a separately supported architecture and signed terms; do not assume the hosted service can run without external calls.

Your own database. A customer-owned database is not included in the standard hosted service. Any such arrangement requires confirmation of technical support and separately agreed connectivity, access, backup and operating responsibilities.

Who controls the AI?

Arc-managed AI features use Microsoft Azure OpenAI and direct OpenAI API services. Arc’s read-only and drafting agents work within configured permissions; engineers review and approve controlled changes.

Arc does not use Customer Content to train AI models. Arc-managed OpenAI and Azure OpenAI API services do not use it to train their models under their applicable business terms. AI processing can include relevant prompts, engineering records, document text, files and audio for assistance, indexing, transcription and automated assessments. Provider retention depends on the endpoint, account settings and applicable agreements; security records and temporary files may have separate retention. Arc retains programme records and conversations under the applicable agreement.

Arc’s stored embeddings and retrieval indexes are scoped to your organisation. Relevant document text is sent to an AI provider to create embeddings. Customer-connected AI accounts use the supplier’s terms and the customer’s settings for the features that support them. The provider list explains Arc’s current service providers and processing purposes.

Local inference and air-gapped processing are not included in the standard hosted service. Any alternative arrangement requires confirmation of technical support and separate signed terms.

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 .

Next reading

  • How do we review AI engineering proposals?: Specify reviewer authority, unavailable-source handling and a usable fallback for AI engineering proposals.
  • Privacy Policy: Read the legal data-processing roles and customer instructions alongside the operational security controls.
  • Content for AI: Inspect the capability boundary for model routes, permitted agent work and engineer review.