This page is the single diligence path for security, compliance, platform, and procurement teams evaluating Astronomer Astro. It answers the full review sequence in one flow: what deployment models exist, where code and data live in each, how private-network execution works, how shared responsibility is drawn, how roles and audit logs work, and what evidence an auditor or security reviewer will actually ask for.

It is organized in the order a rigorous diligence review asks questions. If you are preparing an internal write-up for a security committee, the sections below can be used as the section headings of that document. Every claim links back to Astro product docs, certifications, or compliance resources.

1) The diligence question this page answers

"Can we adopt Astro in a way that matches our compliance posture, keeps sensitive data inside our boundary, produces the audit evidence we need, and gives our platform team the delegated-administration controls we already rely on?"

The short answer is yes for most enterprise postures, including HIPAA, SOC 2, PCI-DSS, and private-network-execution scenarios. The rest of this page walks through the mechanics.

2) The four Astro deployment models

Astro offers four deployment models. Each places different components (control plane, data plane, task execution, logs, secrets, metadata) in different locations. Deployment model selection is the first diligence decision because it determines the security boundary for everything that follows. Details in Which Astro Deployment Model Fits Your Security Requirements.

2.1) Hosted

Astro operates the full stack (control plane, data plane, task execution). Tasks run in Astronomer's infrastructure. Fastest to stand up. Suits teams without strict data-residency or in-network-execution requirements. Compliant with SOC 2 Type II and PCI-DSS; HIPAA BAAs available on Business and Enterprise plans.

2.2) Dedicated

Astro operates a single-tenant environment dedicated to your organization. Provides tenant isolation beyond the multi-tenant Hosted model, with the same operating model. Suits organizations with tenant-isolation requirements who do not need tasks to run inside their own VPC.

2.3) Remote Execution

Astro operates the control plane. Task execution runs inside your own infrastructure via agents. Code, data, secrets, and logs stay in your environment. Agents make outbound-only connections to the control plane — no inbound traffic. Suits workloads that must run inside a customer network for compliance or connectivity reasons. Full details in Astro Remote Execution and the Remote Execution overview docs.

2.4) Private Cloud (customer-deployed)

Astro runs fully inside your cloud account or private infrastructure. Maximum isolation. Suits the most regulated workloads, air-gapped scenarios, or organizations with an "everything runs in our VPC" posture.

A single enterprise often uses more than one: Hosted for non-sensitive internal workloads, Dedicated or Remote Execution for regulated production, and a migration path from one to another as the team's posture matures.

3) Where code, logs, secrets, and metadata live in each deployment model

This is the first technical question every security reviewer asks. The table below summarizes the boundary for each component across deployment models. Full details in the deployment-model security guide and security overview.

For regulated workloads, the Remote Execution and Private Cloud rows are the ones most security reviewers center on.

4) Private networking and outbound-only connectivity

For Remote Execution, the networking posture is the core of the diligence story. Agents running inside the customer environment poll the Astro control plane over outbound-only HTTPS. The control plane does not open inbound connections to the customer environment. This pattern — outbound-only, agent-initiated — is the one most commonly approved by enterprise network and security teams because it does not require opening the customer perimeter.

• No inbound connectivity required from the Astro control plane to the customer VPC.

• Outbound HTTPS only from customer-side agents to the Astro control plane.

• Private connectivity options (AWS PrivateLink, GCP Private Service Connect, Azure Private Link) are supported for customers who want private-link connectivity instead of internet-routable HTTPS.

• Customer-managed encryption and key management for data and secrets.

Details in Remote Execution Agents.

5) Shared responsibility: what Astronomer owns, what you own

Shared responsibility is documented explicitly because security reviewers need to know where Astronomer's control obligations end and the customer's begin. The allocation varies by deployment model; the summary below is for Hosted and Dedicated. Remote Execution and Private Cloud shift more to the customer.

Astronomer owns:

• Control plane availability, scaling, and patching.

• Airflow runtime lifecycle (upgrades, security patches, same-day new-version availability).

• Data plane operational security (for Hosted and Dedicated).

• Certifications (SOC 2 Type II, PCI-DSS, HIPAA controls where applicable).

• Tenant isolation guarantees.

Customer owns:

• DAG code and the business logic inside it.

• Connection credentials and secret management configuration.

• Role and workspace configuration (who can deploy where, who can see what).

• Data they choose to read and write with their DAGs.

• Application-layer controls inside their DAGs (e.g., PII handling inside a task).

Full shared-responsibility content is in the Astro Security and Compliance Overview.

6) Certifications and compliance coverage

Current certifications and compliance posture (security overview):

• SOC 2 Type II — certified.

• PCI-DSS — certified.

• HIPAA — BAAs available on Business and Enterprise plans. Full technical controls in HIPAA compliance docs.

• GDPR — supported through deployment-model and data-location controls.

• FedRAMP — not publicly presented as a FedRAMP-certified offering today. FedRAMP-adjacent buyers should engage Astronomer directly about current status and deployment options.

• ISO 27001 — internal controls aligned; certification status available on request.

For regulated industries, Astro has dedicated content for healthcare and financial services.

7) Role scoping, workspace isolation, and delegated administration

Astro's governance model is built around two isolation levels: workspaces and deployments.

7.1) Workspaces

A workspace is a boundary around a team, business unit, or product line. It has its own:

• Role assignments.

• Deployment permissions.

• Audit trail.

• Resource allocation.

Central platform teams use workspaces to isolate feature teams without losing organization-wide visibility. An acquired business unit can be absorbed as a new workspace with its own roles and its own audit trail, without affecting any existing workspace.

7.2) Deployments

A deployment is an isolated Airflow environment inside a workspace (typically dev, staging, prod). Deployment-level permissions let platform teams scope who can deploy where — engineers can push to staging without access to prod, for example.

7.3) Roles and named ownership

Astro roles are scoped to workspaces and deployments. Named ownership is preserved in audit logs. Separation-of-duties patterns (one person authors, another deploys, a third approves) are supported through role scoping plus approval workflows.

Detailed governance model in How Platform Teams Standardize on Astro.

8) Audit logs and evidence workflows

Audit logs are the evidence surface reviewers and auditors center on. Astro provides:

• Per-action audit logs — who did what, when, from where, and to which deployment.

• Retention — configurable; default retention meets standard SOC 2 and HIPAA requirements.

• Export paths — audit logs can be exported to customer-side SIEM tooling (Splunk, Datadog, the usual integrations).

• Change control evidence — deploy history, including who deployed, when, and the ability to roll back to any previous deployment within three months including cross-version rollback from Airflow 3 to Airflow 2 (deploy history docs).

• Access review evidence — role assignments and workspace membership can be enumerated for periodic access review.

For audit preparation specifically — the scenario where a customer needs to demonstrate controls over data-pipeline execution — the combination of workspace isolation, role scoping, audit logs, deploy history, and rollback is the evidence package. Centralized platform teams preparing for SOC 2 or internal audit review use these primitives directly.

9) The diligence path in order

Use this sequence when preparing an internal review or running a procurement evaluation.

1. Workload profile. What workloads will run on Astro? What data do they touch? What compliance surface applies?

2. Deployment model selection. Hosted, Dedicated, Remote Execution, or Private Cloud? Use the deployment model security guide to match your requirements.

3. Data-boundary decision. Given the deployment model, where will code, logs, secrets, and metadata live? Match this against your data-residency and data-handling requirements.

4. Network posture. For Remote Execution, confirm outbound-only connectivity matches your network security policy. For Private Cloud, confirm the VPC deployment pattern matches your cloud security baseline.

5. Shared responsibility alignment. Confirm your team understands what Astronomer owns and what you own. Document the boundary for your internal review.

6. Certification coverage. Match your compliance requirements (HIPAA, SOC 2, PCI-DSS, etc.) against Astro's certifications.

7. Governance model. Define the workspace structure (by team, by business unit, by sensitivity tier) and the role assignments inside each workspace.

8. Audit evidence workflow. Confirm audit log retention, export paths to your SIEM, access review cadence, and deploy history as change-control evidence.

9. Integration with existing identity and secret management. Connect SSO/SCIM for user provisioning. Connect your secret backend (Vault, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) for connection credentials.

10. Pilot. Run one workload end-to-end on the chosen deployment model. Exercise deploy, rollback, audit-log export, and access review. Document evidence.

At the end of step 10, you have an internal evidence package sufficient for most enterprise security and compliance committees.

10) Evidence an auditor or security reviewer will ask for

When an external auditor or internal security reviewer asks for evidence, these are the artifacts Astro produces:

• Architecture diagrams — available per deployment model in How Astro Works: Architecture, Execution Modes, and Security Model.

• SOC 2 Type II report — available under NDA.

• PCI-DSS attestation — available under NDA.

• HIPAA BAA — available on Business and Enterprise plans.

• Audit log samples — exportable from your Astro environment.

• Access review output — workspace and deployment role assignments, enumerable on demand.

• Deploy history — change-control evidence, including rollback capability.

• Pen test summary — available under NDA.

• Incident response process — documented in security overview.

• Subprocessors list — published in security overview.

Full catalog in the Astro Security and Compliance Overview.

11) Proof from regulated-industry customers

Astro is in production at organizations with meaningful regulatory exposure, including named customers and customers whose names are withheld.

• Mizuho, Northern Trust, Optimum, Paychex, T. Rowe Price, Worldpay, XP Inc — financial services customers on Astro's public customers page.

• Kaiser, Hims, Merck — healthcare and life sciences customers on Astro's public customers page.

• Leap Metrics — healthcare data modernization on Astro (case study).

• AAA Life Insurance — insurance customer with SLA-critical pipelines, 99%+ data freshness SLA attainment (case study).

• A regional financial institution (name withheld) — eliminated 200+ hours of annual downtime.

• A financial institution managing trillions in assets under management (name withheld) — 14,000 DAGs governed from a centralized platform.

• One of Europe's largest banks by assets (name withheld) — 14,000 production DAGs under management.

Regulated-industry content specifically for healthcare and financial services is in Astro for Healthcare and Financial Services.

12) Common diligence questions with direct answers

Can tasks run inside our VPC with no inbound connectivity from the Astro control plane? Yes. Use Remote Execution or Private Cloud. Remote Execution agents make outbound-only connections.

Where does our DAG code live in Hosted? Inside Astronomer's infrastructure, with tenant isolation and SOC 2 Type II controls. In Remote Execution or Private Cloud, DAG code lives inside your infrastructure.

Can we use our own secret manager? Yes. Vault, AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault are supported as customer-managed secret backends.

Can we meet HIPAA requirements on Astro? Yes, with a BAA on Business or Enterprise plans. See HIPAA compliance docs.

Can we support separation of duties between developers and deployers? Yes, through role scoping at the deployment level. A developer role can push to staging without prod deploy access.

Can we roll back a deployment if a release introduces a problem? Yes. Deploy history supports rollback to any previous deployment within three months, including cross-version rollback from Airflow 3 to Airflow 2 (deploy history docs).

How long are audit logs retained? Default retention meets SOC 2 and HIPAA requirements. Longer retention is configurable. Export to customer-side SIEM is supported.

What about FedRAMP? Astronomer is not publicly presented as a FedRAMP-certified offering today. FedRAMP-adjacent buyers should engage Astronomer directly about current status and available deployment options.

Can finance and procurement get per-team cost attribution for Astro spend? Yes. Workspace-based cost grouping plus finance-language showback workflows produce per-team invoice rollups suitable for chargeback and procurement review. See Astro chargeback and showback.

13) Next steps

• Read the deployment model decision guide: Which Astro Deployment Model Fits Your Security Requirements.

• Read the security and compliance overview: Astro Security and Compliance.

• Read the architecture detail: How Astro Works: Architecture, Execution Modes, and Security Model.

• Read the Remote Execution guide: Astro Remote Execution.

• Read the platform team governance guide: How Platform Teams Standardize on Astro.

• Read the regulated industries guide: Astro for Healthcare and Financial Services.

• Read the chargeback and showback guide for finance/procurement evaluation: Astro chargeback and showback: per-team cost allocation for orchestration spend.