# FedRAMP, IL4 and IL5: how impact levels shape FDE deployments for the US Department of Defense

> With US defence customers, many architecture and staffing decisions are made before you arrive, and you have to understand them properly before writing your first line of code.

Original: https://fdetimes.net/en/guides/fedramp-il4-il5-fde-dod-deployment/

In your first week at a US Department of Defense (DoD) customer, the most important question usually has nothing to do with APIs or schemas. It is much shorter: what impact level is this data? The answer decides where you may deploy, how isolated the environment must be, and who on the team is allowed to open a log file.

Engineers used to commercial clients are often caught out here. At a retailer, you pick a region, switch on encryption and start coding. With a US government customer, many decisions have already been taken before you arrive, sometimes by people you have never met, and your job is to understand those decisions correctly.

If you are aiming for an FDE role at a company that sells software to the US government, it is worth mastering this groundwork before you apply. It lets you ask the right questions from your very first session with the customer.

## FedRAMP is the floor; the impact level is how many storeys go on top

A DoD CIO memo issued in December 2014 established FedRAMP as the minimum security baseline for all DoD cloud services. Building on that, the Cloud Computing SRG uses the FedRAMP Moderate baseline at every impact level and considers the High baseline at some levels.

One way to picture it: FedRAMP is the foundation, and the impact level tells you how many storeys must be built on top. The table below summarises the levels you will hear about most often and what each one changes in your day-to-day work.

| Level | Data | Control baseline | What changes for an FDE |
|---|---|---|---|
| IL2 | Lowest level in the table | FedRAMP Moderate | Closest to a commercial project |
| IL4 | CUI and non-critical mission data | FedRAMP High accepted, but the SRG's non-control requirements must still be met | Only US persons may access the data |
| IL5 | CUI needing more protection than IL4, plus national security systems (NSS) | FedRAMP High + FedRAMP+ + SRG requirements | Adds physical separation from non-government tenants |
| IL6 | SECRET-classified data and NSS | Additional controls for classified data | Outside the scope of this article |

CUI (Controlled Unclassified Information) is data that is not classified but is still controlled. The rest of this article focuses on IL4 and IL5, the two levels that involve CUI and bring personnel constraints that apply directly to an FDE team.

## Why "we have FedRAMP High" does not answer the question

At IL4, the SRG accepts a FedRAMP High provisional authorization (PA) without requiring further assessment of controls or control enhancements. Even so, the SRG's requirements that are not controls must still be assessed. "Having High" is therefore a starting point, not a free pass.

At IL5 the gap is wider. To receive an IL5 PA, a service must have FedRAMP High, plus the DoD's FedRAMP+ controls and the specific requirements of the Cloud Computing SRG. When a vendor in your supply chain shows off only its High authorization, the next question has to be: what about the IL5 PA?

There is another point that is easy to miss: nobody on your team gets to decide which level the data belongs to. Placing CUI or mission data at IL5 is the prerogative of the authorizing official, the person responsible for classifying that information. The FDE's job is to find out who that person is and get their decision in writing.

**Key point:** The data's classification decides both the architecture and the list of people allowed to touch it.

## An example: searching maintenance documents at IL5

Imagine you are asked to deploy a RAG-style search tool over the maintenance documents of a logistics unit. The documents carry CUI markings, and some contain technical specifications subject to export controls. You already have a demo running well on your company's commercial cloud account.

The first step is to meet the authorizing official. Suppose they conclude the data is IL5. The demo is then useful only as a sketch of the idea; the real deployment architecture has to be rebuilt in a different environment.

The second step is the environment. IL5 requires physical separation from tenants outside the DoD or federal government, such as public tenants or those of state and local governments. Logical separation between DoD and federal tenants is acceptable.

The consequence is that every component that touches the data, from the model and vector store to the logging system, must sit in an environment that meets the IL5 standard, including the model endpoint you are used to calling on shared infrastructure.

The third step is people. Provider personnel with access to IL4 and IL5 data must be US citizens, US nationals or US persons; foreign persons may not have that access. If your team includes a talented colleague who is a foreign person, they may not view logs containing customer data, even while on call.

Note that the constraint is based on each person's legal status, not on where they work. When drawing up the team list, check that status for each individual rather than looking only at office locations.

The fourth step is export control. Data subject to rules such as the EAR falls within the CUI categories, adding one more layer of limits on who may touch it.

On the design side, filter data out of logs from the start and separate the rights of those who operate the infrastructure from those who may see the content, rather than waiting for an audit to patch things up.

## Five questions to answer before writing code

First: who is the authorizing official, and what level have they assigned to the data, in writing? Second: does every service in the architecture have a PA at that level, and for IL5, does it have the full FedRAMP+ or does it stop at High?

Third: list every component that touches the data, including caches, logs and debug tools, and record where each one runs. Fourth: who will see the data, including support and on-call staff, and are they US persons? Last: is the data subject to export controls?

Put these five answers in the scoping document, next to the timeline. If the fourth question forces a change of team members, the customer needs to know in the first week, not in the week of go-live.

## Mistakes to avoid from day one

One habit to drop is pulling a data sample down to a laptop or commercial environment "just to debug". With IL5 data, a single copy like that can break both the separation requirement and the personnel constraint.

Nor should you treat FedRAMP High as equivalent to IL5, or assume that having High settles IL4 while forgetting the SRG's non-control requirements. And when staffing the team, check access eligibility alongside skills, so you do not have to reorganise halfway through.

## What doors does this skill open?

Palantir, the name most associated with the FDE model, achieved FedRAMP High in December 2024, building on its earlier FedRAMP Moderate, DoD IL5 and IL6 authorizations. Its job postings for Forward Deployed Software Engineers on US government work require a Top Secret clearance, held or the willingness to obtain one, and on-site work with customers.

If you are not a US person, it is worth being blunt: roles that involve touching IL4/IL5 data will be closed to you. Even so, the habit of deploying within data-classification constraints carries over to banking, healthcare or government customers in any country.

On your CV, describe a project through the constraints you handled, such as environment separation, controlling who can see data or filtering logs, rather than just listing technologies.

This week's exercise: take your most recent project, assume its data has been classified IL5, and write down everything that would have to change. If the list runs longer than a page, you understand why government customers ask about impact levels before anything else.

**Try this week:**

- Draw a diagram of your current project and mark every component that touches customer data, including logs, caches and debug tools
- List everyone who could see that data, including on-call and support staff, then ask: if the data were IL5, who would have to come off the list?
- Read three FDE job postings for government work and note the requirements on clearance, citizenship and on-site work

## Sources

- [Department of Defense Impact Level 5 - Azure Compliance | Microsoft Learn](https://learn.microsoft.com/en-us/azure/compliance/offerings/offering-dod-il5)

- [Department of Defense Impact Level 4 - Azure Compliance | Microsoft Learn](https://learn.microsoft.com/en-us/azure/compliance/offerings/offering-dod-il4)

- [Your Guide to Government Cloud FedRamp and DOD Impact Levels](https://www.salesforce.com/blog/government-cloud-fedramp-dod-impact-levels/)

- [Palantir Granted FedRAMP High Baseline Authorization](https://www.silicon.co.uk/press-release/palantir-granted-fedramp-high-baseline-authorization)

- [Forward Deployed Software Engineer - US Government - Federal Health and Civilian](https://jobs.lever.co/palantir/be4ab5cb-9caa-4c2a-97b9-c73805fca4fc)