Azure Data Factory · FedRAMP Moderate engineering
Azure Data Factory configuration for FedRAMP Moderate systems
Technical how-tos for private, identity-aware ETL and data integration in a verified federal cloud boundary. Choose the runtime and change contract first, then build a reviewable ingestion and release process.
What makes an Azure Data Factory configuration eligible?
Flat Spell Technologies provides enterprise software, government cloud, and compliance engineering. These Azure Data Factory guides apply that engineering approach to orchestration, extract-transform-load (ETL), hybrid data movement, and controlled release of regulated data pipelines. They focus on Data Factory V2; Microsoft Fabric Data Factory has a separate offering and feature model that must be evaluated independently.
A FedRAMP Moderate-aligned design begins with an eligible provider offering and its current package, then maps the application’s implemented and inherited controls. Verify each runtime, connector, feature, region, data store, external compute dependency, and telemetry path. An integration runtime’s execution location and an external service’s processing boundary matter as much as the factory resource’s region.
| Offering / package ID | Current Marketplace status | Profile |
|---|---|---|
| Azure Commercial Cloud — F1209051525 | FedRAMP Certified; Ongoing Certification | Rev5; JAB; Class D (High) |
| Azure Government (includes Dynamics 365) — F1603087869 | FedRAMP Certified; Ongoing Certification | Rev5; JAB; Class D (High) |
Microsoft’s service scope inventory, with Azure public and Government tables marked February 2026, lists Data Factory in FedRAMP High scope in both clouds. A High-scope service can support inherited controls for a Moderate system, subject to the authorized boundary and customer responsibilities. The current Marketplace’s “FedRAMP Certified” label identifies the provider offering; it is not your application’s ATO.
Azure Government is not a universal requirement for every Moderate workload. Choose the cloud required by the agency, data-handling rules, and service availability. Generic commercial examples do not establish Government feature parity. Use the Marketplace package-request process and Microsoft Service Trust Portal for the applicable security documentation.
Reference architecture: private ingestion with explicit publication
- Reviewed orchestration
Factory, trigger state, source contract, bounded batch - Selected runtime
Managed private connections or hardened customer runtime - Restricted stores
Approved source view, landing path, control state, secret access - Verified publication
Schema and key checks, idempotent target, committed cursor
Choose the IR based on the required network and execution model. An Azure IR with managed virtual network can reach supported stores through managed private endpoints. A self-hosted IR supports hybrid movement from a customer-controlled network. Mapping Data Flows execute on managed Azure compute; Azure-SSIS is a distinct runtime design for SSIS packages. Each option needs a feature, location, and responsibility review.
Factory Private Link secures a specific control path, while data stores need their own private connections. Microsoft documents that ADF managed-VNet Azure IR permits outbound communications on all ports; do not treat managed private endpoints as a global egress firewall. The networking guide explains the decision points and scoped public-access behavior.
Choose a technical implementation guide
Private endpoints and runtime networking
Separate factory control, authoring, runtime-to-store, and external execution paths.
Configure private networking →Managed identity and ADLS
Build scoped SQL-to-lake ingestion with private paths, schema validation, and protected publication.
Build managed-identity ingestion →Self-hosted integration runtime
Harden Windows runtime nodes, configure Government dependencies, and rehearse node recovery.
Configure hybrid ingestion →Incremental copy and safe replay
Bound the source window, validate a batch, and commit its checkpoint only after publication.
Design incremental loads →CI/CD to Azure Government
Validate and export ADF resources, parameterize environments, and control endpoint and trigger release gates.
Build reviewed CI/CD →Monitoring, performance, and pricing
Verify redacted diagnostics, data-freshness alerts, runtime bottlenecks, and cost units.
Monitor and budget pipelines →Map implementation outputs to Moderate control evidence
| Concern | NIST SP 800-53 controls / families | Evidence to produce |
|---|---|---|
| Identity and scoped data access | AC-2, AC-3, AC-6; IA-2, IA-5 | Factory/operator roles, SQL permissions, ADLS ACLs, denied access tests |
| Private paths and cryptography | SC-7, SC-8, SC-13, SC-28 | Endpoint approvals, DNS and TLS checks, store settings, reviewed host/driver crypto |
| Recoverable ingestion | SI-10; CP-9, CP-10 | Schema/key reconciliation, durable batch state, cursor commits, tested replay and restore |
| Auditing and monitoring | AU-2, AU-3, AU-6, AU-9, AU-11; CA-7 | Sanitized run records, workspace access, log retention, failure and freshness alerts |
| Controlled change | CM-2, CM-3, CM-6; SI-2 | Pinned delivery dependencies, reviewed artifacts, trigger state, runtime patch evidence |
This mapping identifies useful engineering evidence; it does not demonstrate that every control is fully implemented. Separate provider-inherited controls from customer-managed hosts, application logic, data quality, and operations. Retain evidence with its environment, configuration version, review date, and result.
Deployment checklist and release gate
- Record the cloud offering, current package reference, application boundary, approved services, regions, and customer responsibilities.
- Choose the runtime and verify its actual execution location, connector support, and network model.
- Provision source, sink, control state, secret, DNS, and private endpoint dependencies; verify approvals and public-path restrictions.
- Grant scoped identities and test denied reads, writes, and destinations separately from network checks.
- Define a schema and change contract, immutable batch window, validation rules, publication decision, and checkpoint commit.
- Run node, connector, replay, retention, and data-quality failure tests using synthetic data.
- Release reviewed artifacts with trigger state control, redacted monitoring, documented recovery, and measured cost units.
The examples are configuration and algorithm excerpts, not a complete provisioned environment. Live identity, network, pipeline, SQL, monitoring, and billing acceptance tests remain to be run in your approved environment. The website deployment uploads static pages and assets only.
For the next stage of a data-to-AI architecture, review the Azure AI Foundry resource hub. For platform preparation, use the Azure Government migration checklist.
Sources and technical review
Technical review: . Recheck cloud, regional, connector, and authorization scope before implementation.
- Azure Data Factory overview
- Integration runtime capabilities and geography
- Managed virtual network and egress limitations
- Data Factory Private Link limitations
- Azure service compliance scope inventory
- Current FedRAMP Marketplace
Public offering and service-scope checks are documented in the Data Factory hub. The protected provider authorization package and live Azure behavior have not been reviewed or tested by these guides.