“Is ServiceNow FedRAMP authorized?” is the question that gets asked, and answering it yes is accurate and almost useless. It settles one of three things a federal programme needs settled, and it is the one that was never really in doubt.
Three separate things get compressed into that single question, and keeping them apart is most of the work.
- The cloud offering’s authorization. A FedRAMP determination about a specific cloud service offering, at a specific impact level, with a defined boundary. This belongs to the provider.
- Your agency’s authority to operate. A decision by your authorizing official that your system — the platform plus what you configured, built and connected on it — may run and carry your data. This belongs to you, and no provider authorization grants it.
- The controls you inherit. The subset of the control baseline the provider satisfies on your behalf, versus the subset that remains yours. This is the part almost nobody prices before starting.
What the provider’s authorization covers
ServiceNow operates a separate government environment — GovCommunityCloud — distinct from its commercial cloud, and states that it holds FedRAMP High and DoD Impact Level 4 authorizations for it (ServiceNow).
Two caveats worth stating plainly. First, this applies to that environment and to the specific products in its boundary — not automatically to every ServiceNow product, and not to a commercial instance. Newer offerings reach authorization on their own timelines and at their own levels. Second, authorization status and offering names change, so a page like this one is not a source of truth. The FedRAMP Marketplace is, and checking the specific offering you intend to buy takes two minutes.
If a vendor — including a consultancy — tells you a product is authorized and does not name the offering and the level, ask them to. The distinction is not pedantry; it is the thing your authorizing official will ask about.
You still need your own authorization
An authorized cloud service does not carry an agency system across the line. It gives you a large, pre-assessed foundation to build a package on top of, and it removes a great deal of assessment work. It does not remove the package.
The practical consequence is scheduling. Programmes that treat the provider’s authorization as the compliance milestone discover the real one late, usually when a security team asks for a control implementation summary describing configuration decisions that were made months earlier for unrelated reasons.
The part that surprises people: what stays yours
Inheritance is partial and it is documented. The provider publishes which controls it fully satisfies, which are shared, and which are entirely the customer’s. That last category is larger than most people assume, and it is populated by exactly the things a platform team decides week to week:
- Access control and roles. Who holds admin, how elevation is granted, how it is reviewed. Every one of those is a control you own and can weaken by configuration.
- Identity integration. How authentication is federated, and what happens to accounts that fall outside it.
- What you put in the tables. The environment’s impact level sets a ceiling on data sensitivity; it does not police what a well-meaning administrator stores in a description field.
- Audit configuration and retention. Available out of the box, and configurable to a state that does not meet your baseline.
- Anything you built. Scoped applications, custom tables, business rules, script includes. The platform’s authorization says nothing about the security of code written on it.
What punctures the boundary
The boundary is a design constraint, not a property of the instance. Four things routinely breach it, and all four are ordinary platform work:
Integrations to systems that are not themselves authorized. A flow that sends data to a commercial SaaS tool moves that data outside the boundary regardless of how the connection is secured. This is the most common finding, and it usually arrives as a convenience integration nobody thought of as an architecture decision.
MID Server reach. A MID Server is deliberately a bridge between the instance and your network. What it can reach, what credentials it holds and where it sits are boundary decisions, and they tend to be made by whoever is doing the install.
Custom applications and third-party store applications. An application installed from a store inherits the platform’s hosting, not an assessment of itself. Store listings and authorization status are separate questions.
Data egress for reporting and analytics. Extracts to a warehouse, a BI tool, or an AI service are egress. Where AI features are involved, establish specifically which offering processes the data and whether that offering is in the boundary — this is the fastest-moving area and the one where assumptions age worst.
What the 2026 rules change
FedRAMP is mid-transition, and the vocabulary in front of you is about to shift. Under the consolidated 2026 rules, “FedRAMP authorization” is being reframed as FedRAMP Certification — explicitly to stop it being confused with an agency’s authority to operate. Impact levels are being expressed as Certification Classes, continuous monitoring becomes Ongoing Certification, and Plans of Action & Milestones become documented Accepted Weaknesses. The rules took effect in July 2026, with mandatory enforcement from January 2027 (FedRAMP).
Nothing about the underlying distinction changes — a certification is still not your ATO — but for a year or so you will see both vocabularies in circulation, sometimes in the same document set. Read for which of the three things above is being claimed rather than for the word.
Questions worth settling before anything is designed
- Which specific offering, at which level, and is that verified on the Marketplace rather than in a slide?
- What is the highest sensitivity of data that will land in the platform — including in free-text fields and attachments, not just the fields on the design?
- Which controls are inherited in full, which are shared, and who on your side owns each shared one by name?
- What is the complete list of systems this platform will connect to, and what is the authorization status of each?
- Who authorizes a new integration after go-live, and does that person know the boundary exists?
The last one is the one that decays. Boundaries are usually correct at go-live and eroded eighteen months later by a series of individually reasonable decisions, none of which was reviewed as a boundary decision because no one had that job.
Where Tessivant sits, stated plainly
A services firm cannot be FedRAMP certified. The determination applies to cloud service offerings, not to consultancies — so any consultancy describing itself as FedRAMP certified is claiming something that does not exist, and that is a useful thing to notice about a vendor early.
What a services firm can do is design inside a boundary, document decisions so they survive an assessment, and say clearly when a requested integration would take data outside it. That is our position: we hold no FedRAMP authorization and no certification, because neither is available to a firm like ours, and we will tell you when a design choice has a compliance consequence before it is built rather than at assessment.
We are also not your authorizing official, your assessor or your counsel, and this page is background rather than advice. Verify the current status of any offering on the FedRAMP Marketplace, and take control determinations to the people accountable for them.