DoD Impact Levels, explained (and what they mean for a local-first app)
Posted: June 24, 2026 · 7 min read
If you work in or around the U.S. Department of Defense, you have probably seen terms like "IL4," "IL5," and "FedRAMP" attached to the software your team is allowed to use. They sound intimidating, and the rules behind them are genuinely detailed. But the core idea is simple, and once you understand it, you can see exactly where a local-first tool like manyCalendars fits. This post explains Impact Levels in plain language and is honest about what manyCalendars is and is not.
What are DoD Impact Levels?
Impact Levels come from the Department of Defense Cloud Computing Security Requirements Guide (the "Cloud Computing SRG"), which is managed by the Defense Information Systems Agency (DISA). An Impact Level is a risk tier. It combines two things: how sensitive the data is, and how bad it would be if that data were exposed. The more sensitive the information, the higher the level and the stricter the controls a cloud provider must meet.
| Level | What kind of data it covers |
|---|---|
| IL2 | Non-controlled, unclassified information. The lowest tier, for general public or low-sensitivity data. |
| IL4 | Controlled Unclassified Information (CUI). Sensitive but unclassified data that law or policy says must be protected. |
| IL5 | CUI that needs higher protection, plus unclassified National Security System (NSS) data. The highest unclassified tier. |
| IL6 | Classified information up to the Secret level. A different world, with its own dedicated networks. |
Under the hood, these tiers build on the federal FedRAMP program. The DoD generally starts from the FedRAMP Moderate security baseline and then adds its own extra controls on top, with the requirements getting stronger as you move from IL2 up to IL5. A cloud provider that meets all of this for a given level can receive a DoD Provisional Authorization (a "PA") from DISA for that service.
Do Impact Levels apply to every piece of software?
No, and this is the part that trips most people up. Impact Levels were written for cloud service offerings: services that take in government data, store it, and process it on a provider's servers. The whole framework is about protecting data that lives in someone else's cloud.
Software that runs entirely on your own device, and never sends your data to a server, is a different category. It is endpoint software, and it is reviewed differently. Instead of a cloud Impact Level, a local tool is typically handled through your organization's own software approval process: things like a software bill of materials (SBOM), a security review of the code, and being added to an approved-software or allowed-extensions list for managed machines.
How does manyCalendars fit into this?
manyCalendars is local-first by design. It is a browser extension that merges the calendars you can already see into one private view, and that merging happens inside your own browser. Your calendar data is not uploaded, synced, or copied to our servers. There is no server-side copy of your schedule to authorize, because we never receive it.
Because of that, the extension itself is not a cloud service offering, so it is not the kind of thing that gets assigned an IL4 or IL5 rating. The only part of manyCalendars that talks to a network at all is a small backend used for license checks, email sign-in, and billing. That backend never sees your calendar events, attendees, or meeting details. It exists to confirm your plan, not to read your day.
Is manyCalendars FedRAMP or IL authorized?
No. To be completely clear: manyCalendars is not currently FedRAMP authorized, and it has not been assigned a DoD Impact Level. We are not on the FedRAMP Marketplace and we hold no DoD Provisional Authorization. This article explains how our architecture relates to those frameworks. It is not a claim that we have been certified by anyone.
We would rather state that plainly than imply something we have not earned. If your environment requires a tool to carry a formal authorization, manyCalendars does not meet that bar today, and you should treat it accordingly.
Why local-first matters in high-security environments
The reason the cloud security frameworks exist at all is that putting sensitive data on a third party's servers creates risk that has to be managed, audited, and continuously monitored. A local-first tool sidesteps the root of that problem: when your calendars are read and merged on your device, not in our cloud, there is no third-party cloud holding it, nothing to breach on our side, and nothing for us to be trusted with.
That lines up with a principle every security team already follows: collect and expose the least data possible. With manyCalendars, the answer to "what does the vendor store about my schedule" is "nothing." For people whose calendars carry confidentiality obligations, that is the entire point.
What this means if you work in a regulated or government setting
Two practical takeaways:
1. The right review for a local extension is your endpoint process, not a cloud ATO. Because manyCalendars runs on your device and keeps data local, the relevant question for your security team is usually whether the extension can be added to your organization's allowed-software or allowed-extensions list, not whether it carries an Impact Level. We are happy to provide details about how the extension works to support that review.
2. Always follow your organization's rules. Whether a piece of software is permitted on a government or contractor machine is a decision for your own IT, security, and authorizing officials. Nothing here overrides your local policy. If you are unsure, ask your security team before installing.
The short version
DoD Impact Levels (IL2 through IL6) rank how strongly a cloud service must protect the government data it stores. manyCalendars keeps your calendar data on your own device and never sends it to a server, so the extension is not a cloud service that receives an Impact Level. We are not FedRAMP or DoD authorized, and we do not claim to be. In a restricted environment, treat manyCalendars like any other local tool: route it through your organization's software approval process, and let your security team make the call. Install manyCalendars for free and keep your schedule on your own machine.