FedRAMP Hosting: How Authorization and ATOs Work

FedRAMP Hosting: How Authorization and ATOs Work

Most of the advice about FedRAMP hosting gets the priority order wrong. It says: pick a government region, choose a provider that appears on the FedRAMP Marketplace, and the compliance question is handled. That advice survives right up until an authorizing official asks which cloud service offering was assessed, what the boundary includes, who inherited which control, and where the last four quarters of evidence live.

Those four questions are the compliance case. The region is a footnote in it. A hosting claim holds up when the boundary is documented, the inherited controls are stated in writing, and the provider can produce fresh evidence on a fixed cadence for as long as the agency runs the system. A claim built only on where the servers sit collapses at the first significant release.

What follows is how those claims get built, tested and maintained, written for the teams who have to defend the decision in a review room.

Table of Contents

Region, Authorization and ATO Are Three Different Claims

A compliant region, a FedRAMP authorization and an agency authority to operate answer three separate questions, and treating them as one claim is how a hosting pitch survives the sales call and fails the review. Each layer has a different owner, and only one of the three belongs to the agency.

Start with geography. A government region is a fact about where compute and storage run and which regional infrastructure controls apply. It says nothing about whether the service running on top of it was ever assessed against federal controls. The region is the smallest part of the compliance case.

An authorization is a claim about one defined cloud service offering, its system boundary and the controls inside that boundary. A company can sell several offerings under one brand and hold an authorization for only one of them, which is why the offering name and its documented boundary matter more than the logo on the slide. An authority to operate is narrower again: the agency's own risk decision for its own system, issued by its own authorizing official, and it does not travel to another agency.

The diagram below keeps the three from collapsing into one line in a scoping call.

A diagram illustrating the three key pillars of FedRAMP: Region, Authorization, and Authority to Operate (ATO).

How a provider earns the claim

FedRAMP was established by the U.S. Office of Management and Budget in 2011 and is administered by the General Services Administration, so agencies stop repeating near-identical security reviews of the same cloud service, as the GAO's review of FedRAMP describes. The provider documents the offering and its system security plan, an independent third-party assessment organization tests the controls, FedRAMP authorizes the offering, and the agency sponsor then runs its own authorization on top of that package.

Status carries as much weight as the vendor name. As of July 31, 2025, the FedRAMP Marketplace listed 585 cloud service offerings with a formal designation: 451 authorized, 69 in process and 65 ready, per Secureframe's 2025 marketplace figures. An in-process listing is a queue position, and a buyer who reads only the logo learns nothing about which column that offering occupies.

Where workloads run and who controls them are two different questions, the same confusion that muddies residency claims. A comparison of data sovereignty and data residency explains that distinction in detail.

Layer What it covers Who signs or decides Common mistake
Compliant region Physical location and regional infrastructure choice Cloud infrastructure provider and hosting team Treating a government region as proof of authorization
Provider FedRAMP authorization A defined cloud service offering, its boundary and its assessed controls FedRAMP authorization process Assuming the whole platform is covered when only one offering is
Agency ATO The agency's risk acceptance for its own system Agency authorizing official Assuming a provider authorization removes the agency's decision

Copy all three layers into the procurement file before the first vendor call, and ask every vendor which layer each claim refers to. WebinOne, for instance, can be deployed as a licensed version running in a qualifying systems integrator's own AWS account or their client's, including AWS GovCloud for government projects, by agreement. Whatever the deployment model, boundary and status answers belong in writing, where they can be reviewed.

Picking the Impact Level Before the Provider

Classify the workload before reading a single authorization claim, because the impact level is what turns an authorization into an answer about this system. Do the scoping in that order: workload and data first, provider evaluation second. The data center region enters this calculation barely at all. What matters is what the workload holds and what losing it would cost.

FedRAMP impact levels are set by the consequences of losing confidentiality, integrity or availability, and they determine what sort of federal workload a hosting environment can support. The CMS security guidance on FedRAMP sets out the three.

  • Low impact covers solutions whose compromise doesn't involve sensitive personally identifiable information. Publishing pages, public documents, general contact routing.
  • Moderate impact applies where a security failure could cause serious adverse effects: significant operational damage, financial loss, or physical harm that stops short of loss of life.
  • High impact is reserved for systems such as law enforcement, emergency services, financial and health systems, where compromise could produce severe or catastrophic effects.

A worked case makes the shift concrete. A public information site that publishes notices and opening hours might sit at low impact on its own. Add a benefits or permit form that collects personal data and the classification changes, because the cost of a breach now includes every person in that form. The platform didn't change.

The data changed the answer.

Three steps settle most of it:

  1. List every data type the workload holds, including form fields, log contents, integration payloads and anything support staff can see.
  2. Estimate the consequence of losing confidentiality, integrity or availability for each type separately. One data type can pull the whole system up a level.
  3. Take the highest result as the working level and write the reasoning next to it, so the decision can be reviewed rather than re-argued.

Working rule: treat an authorization claim with no impact level attached as unanswered. Ask for the level and the boundary first, because nothing else about the offering is worth pricing until both are stated.

Put the chosen level and its rationale in the requirements document before scoring any response, so every claim you receive gets tested against a number you already own. "FedRAMP authorized" without a stated level establishes nothing about fit for a particular agency application.

Splitting Controls Between Provider and Agency

Every control in a federal hosting review belongs to the provider, the agency or both. Ask any provider for a responsibility matrix before scoping begins, because a host that can't produce the matrix usually can't produce the evidence underneath it either.

Rev 5 anchors the whole exercise in the security and privacy controls of NIST SP 800-53 Revision 5. The FedRAMP Rev. 5 control guidance requires the provider to document the complete production architecture, including compute, storage, networking, identity, logging, backup, support access and data flows, and to separate provider-managed controls from agency-managed ones. That document is the spine of the review.

Control area Provider responsibility Agency responsibility Evidence to request
Physical facilities Inherited from the cloud infrastructure provider and documented in the boundary Review inherited controls Inheritance statement in the system security plan
Identity and privileged access Administrative access, support access and secrets management Assign and review user roles Access review records
Logging and monitoring Collection, correlation and reporting of platform logs Review reports and act on findings Sample log and alert records
Vulnerability management Scanning and remediation across the authorized boundary Track findings that affect agency configuration Scan results and remediation tracking entries
Secure configuration Hardened defaults and configuration guidance Apply guidance to agency tenant settings Configuration guide and change log
Change control Impact analysis and updated documentation for releases Approve changes that affect agency use Change impact records
Backup and recovery Backup operation and restore testing Define recovery needs and test with the provider Backup test results
Incident response Detection, containment and reporting procedures Notify and coordinate agency reporting Incident procedure document

Where inheritance gets decided

Physical facility and infrastructure controls are inherited from the cloud infrastructure provider, and the system security plan has to say so explicitly rather than imply it. All WebinOne websites are physically hosted on Amazon Web Services servers, which makes the boundary question concrete: which AWS services, which regions and which WebinOne-operated components sit inside the offering, and which sit outside it.

Multi-tenant platforms carry an extra burden here. Tenant isolation, administrative access, secrets management and release processes have to behave identically across the whole boundary, because a technically secure cloud environment can still fail review when the assessed service doesn't match the service delivered.

The boundary is what gets scored, so draw it before anyone argues about it.

Mark each row of the matrix as provider, agency or shared, then request the inheritance statement and data-flow diagrams for every row marked shared. Shared rows are where handoffs go unwritten. A shared logging row means the provider collects the logs and the agency acts on the findings, and if neither side records who reviews the reports, that control fails on paper even when both teams do their part. That is where the argument starts six weeks before an authorization meeting.

How to Test a Hosting Provider's Authorization Package

Treat the authorization package as a set of claims to test rather than a certificate to file, and put the same checks to WebinOne that you would put to any host. Seven of them do most of the work, and each one exists to close a specific gap.

The checklist below is the short version used in federal evaluations.

A procurement checklist infographic illustrating five steps for evaluating and approving a cloud hosting service provider.

  1. Match the offering, not the company. Confirm the named offering, its designation and its impact level correspond to the exact service you'd buy, not a sister product under the same brand.
  2. Read the boundary. Identify which AWS services, regions and subprocessors sit inside it, and what falls outside. Anything inside your data flow but outside the boundary is your problem to control.
  3. Request three documents and read them against each other. The system security plan, the data-flow diagrams and the inherited-controls statement. If they disagree, stop and get a corrected version.
  4. Open the Plans of Action and Milestones. Look at what's open, who owns each item, and when it closes. Prioritise the open items touching the components you'd use.
  5. Ask how significant changes are assessed before release, and which categories of change trigger agency notice. The answer tells you how much drift to expect in year two.
  6. Confirm the sponsor and the signature. Establish which party runs the ATO and who accepts risk. FedRAMP's certification guidance holds that a provider seeking agency certification must complete an ATO process with its agency sponsor and obtain a formally signed ATO letter, per the FedRAMP certification guidance.
  7. Agree the exit before you sign. Data export format, return timeline, and what happens to agency data if the service is discontinued. An exit plan written after a problem is a hostage negotiation.

Teams weighing how much of a managed runtime can sit inside an assessed boundary, and how much configuration stays with the customer, will find a closer look at Cloud Run useful for seeing where that line is drawn in practice.

The policy rule shapes the agency's side of the decision. When a cloud product holds a FedRAMP authorization at a given FIPS 199 impact level, agencies must presume the assessment documented in the package is adequate for their own authorization to operate at or below that level, but the authorizing official still issues the agency authorization and the agency still monitors the system, according to FedRAMP's guidance on ongoing use. Reuse reduces duplicated assessment work. It doesn't transfer accountability.

For a scoped boundary review, or a licensed deployment in your own AWS account including AWS GovCloud where it qualifies by agreement, start a conversation with the WebinOne enterprise team. The managed AWS hosting overview covers how the underlying platform operations are handled day to day.

Continuous Monitoring Evidence You Should Expect

Treat the evidence cadence as part of the hosting decision, not paperwork that follows it. An authorization package describes one assessment window. What you are buying is the stream of proof that keeps the package current between windows.

Evidence Frequency
Key security metrics Monthly
Ongoing Certification Report Every three months
Annual monitoring evidence Annually
Reassessment cycle Every three years
Significant change or incident notice When the event occurs

The reporting mechanics are specific enough to hold a provider to. FedRAMP's collaborative monitoring rules require an Ongoing Certification Report to the necessary parties every three months, covering the period since the previous report in a consistent, human-readable format, while the continuous-reporting standard requires key security metrics updated at least monthly and retained for agencies and FedRAMP for 24 months after initial reporting, per the FedRAMP collaborative continuous monitoring rules. That retention window matters in practice: an authorizing official can reach back two years, so a gap in any single month stays visible long after the quarter closes.

The wider cadence comes from a monitoring model built on NIST SP 800-137, with evidence produced on monthly, annual and three-year cycles and again when a specific event requires it. Providers stay primarily responsible for keeping the controls in the system security plan effective, not merely implemented once, as the FedRAMP continuous monitoring playbook sets out.

What should already be automated

Manual assembly is the tell. If a compliance analyst rebuilds the quarterly package from spreadsheets each time, the pipeline isn't operating, it's improvising. Ask which of these streams feed control evidence automatically, and where a human still has to pull them together:

  • Infrastructure and application logs, mapped to the logging controls they satisfy.
  • Privileged-access events, including support access, joined to access review records.
  • Configuration changes, matched to the change records that approved them.
  • Vulnerability findings with remediation dates, tied to scan and remediation controls.
  • Incident records and backup restore tests, with dates and outcomes.
  • Control-test results, retained long enough to survive a two-year look back.

Each item on that list maps to a row in the evidence table. If a stream exists but nobody can say which control it feeds, it won't appear in the quarterly report in usable form.

Operational test: ask for the latest quarterly report and the previous twelve monthly metric sets. If the provider needs a week to find them, the monthly cadence is a claim, not a practice.

Agencies run their own continuous monitoring programs and review these reports at risk-appropriate intervals, so the provider's rhythm has to line up with the agency's review calendar. A report delivered late lands after the review it was meant to inform. Where evidence covers integrity checks, file integrity monitoring explained shows what a reviewable trail looks like rather than a clean dashboard screenshot.

Authorization Drift and the 2026 to 2027 Transition

The buying question has shifted from whether a host is FedRAMP authorized to how it stays authorized while the product changes. A fast first authorization matters less than the state of the package after a year of releases.

Drift appears when a release changes architecture, code, AWS services, regions or subprocessors and the documentation stays behind. Nothing fails loudly. The package stops describing the service that is running. Release engineering has to include change impact analysis and updated documentation whenever those elements shift, and a mature pipeline blocks or escalates any change that alters the assessed boundary, which is the discipline the FedRAMP assessment, authorization and monitoring guidance describes.

The program itself is mid-reform, which adds timing risk to any 2026 purchase. Per FedRAMP's FY25 program update, authorization timelines had exceeded one year and sometimes approached two, roughly 90 cloud services sat in the authorization backlog, and the program targeted 50 authorizations in fiscal year 2025 while pursuing faster reviews, machine-readable authorization data, expanded Marketplace listings and new certification designations. The dates FedRAMP has published against that reform turn a paperwork question into a contract question, and each one is a scheduled target that can move.

Date Milestone What it means for your evaluation
July 28, 2026 FedRAMP Ready submissions planned to stop after this date Check whether any provider plan relies on a Ready designation
January 1, 2027 Consolidated rules scheduled to become mandatory Confirm the provider's control mapping matches the consolidated rules
June 11, 2027 New Rev5 certifications scheduled to end Ask which authorization path the provider's offering follows

Four questions separate a host that can absorb a release from one that cannot. How are significant changes defined and approved? How are remediation timelines set and reported? Is evidence produced by automation or assembled by hand? Does the agency's ATO inherit cleanly after a release, or does it reopen?

Add the exit question to the same conversation. If the authorization lapses or the service is discontinued, what is the migration path and who pays for it. Some providers already answer that in their terms: WebinOne commits to open-sourcing its platform if the service closes, so a reseller can keep hosting its own sites, portal and SSO without vendor support. Write the change-management clause into the contract and tie it to the schedule above, so each date lands as a tracked milestone instead of a mid-contract surprise. Apply the same test to every candidate host, WebinOne included, and ask for the significant-change process and a sample release record in writing.

Bring Your Boundary Questions to the WebinOne Team

The strongest evidence in a federal hosting evaluation is a written answer. Assurances about scope, control inheritance and monitoring carry no weight once an authorizing official reviews the package, so measure a provider call by the document it produces, not the demo it gives.

US and Australian government clients already use WebinOne for secure, compliant web presence. The platform runs on AWS across six regions with 99.99% uptime over the last 12 months, and its AWS Partner standing includes a passed Foundational Technical Review and the AWS Qualified Software designation. Those facts justify the conversation. They do not answer the boundary question.

For federal projects, qualifying systems integrators can run a licensed version in their own AWS account or their customer's, including AWS GovCloud, by agreement. Under that model the control-inheritance question changes shape, so ask which controls sit with WebinOne and which land on the integrator or your agency.

Bring three items to the call:

  • The authorization boundary you need documented
  • The impact level for each workload
  • The monitoring cadence your agency will review against

Add a fourth on continuity. If the service is ever discontinued, WebinOne commits to open-sourcing the platform so resellers can keep hosting their sites, portal and SSO without vendor support. Whatever the answer, get it in writing. Written answers are the only form that survives a review.