How to Convert a FedRAMP POA&M into the 2026 Vulnerability Detail Report

On December 7, 2026, FedRAMP stops accepting the POA&M as the way you report vulnerabilities. From that date every certified and in-process cloud service offering, Rev 5 and 20x alike, reports vulnerability detection and response activity as two JSON documents: the Vulnerability Detail Report and the Accepted Vulnerability Info. The grace period ends March 7, 2027.

Most providers have years of findings in a POA&M spreadsheet and a folder of deviation requests. This guide shows how to turn them into the two new documents with Boundera's free POA&M converter, which runs in your browser, and what you have to add by hand because the POA&M never captured it.

Key takeaways

• The POA&M does not become one new file. Open and closed findings go to the Vulnerability Detail Report under VER-RPT-VDT. Findings you will not fix go to the Accepted Vulnerability Info under VER-RPT-AVI.
• Three fields the POA&M never had are mandatory on every open finding: internet-reachability, likely exploitability, and a Potential Agency Impact rating. Scanner severity is not an answer to any of them.
• Deviation requests map cleanly. A false positive closes the finding. An operational requirement makes it an accepted vulnerability. A risk adjustment only suggests the new rating.
• Anything open or scheduled more than 192 days after evaluation is an accepted vulnerability under VER-TFR-MAV, whether or not you ever filed a deviation.
• The converter checks both files against FedRAMP's 2026-06-24 JSON schemas and gives you a gap summary of every value it could not take from your spreadsheet.

What replaces the POA&M on December 7

CISA's BOD 26-04 requires agencies to prioritize remediation by risk. FedRAMP passed that down to providers in Notice NTC-0014 through two rulesets, Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER). The December deadline post covers the timelines. This post covers the reporting format.

Under VER-RPT-PER, reporting becomes persistent: each report summarizes all activity since the previous one. The content of those reports is fixed by two rules and two published JSON schemas.

Both documents share a header: the URL of your certification package overview and the report period. Both are "FedRAMP Certification Data" and follow the data-sharing rules. Agencies may still keep a POA&M of their own from what you report, but you no longer send one.

What to have ready

You need four things before you open the converter.

1. Your POA&M export. The Rev 5 template as .xlsx or .xlsm, or a CSV of one tab. The converter reads the Open and Closed tabs from the workbook. With a CSV it asks which tab you exported, because the status is not in the file.
2. Your deviation requests, optional. The FedRAMP Vulnerability Deviation Request Form is matched to the POA&M by POA&M ID. One request can list several IDs.
3. Your program and class. Rev 5 is Class B, C or D. 20x is Class A, B or C. The class sets the remediation timeframes in VDR-TFR-PVR, and the converter uses them to compute whether a finding is overdue. The VDR and VER timelines page lists them.
4. The URL of your certification package overview. The schemas require it as a valid URI. Without it you can still export a draft.

The fifth thing is judgment. For every open finding you will confirm three evaluations and the date you completed them. The next sections show where.

Step 1: Import files

Drop the POA&M on the first slot and the deviation request form on the second. Files stay in browser memory. Nothing is uploaded, and reloading the page clears the session.

If you want to see the whole flow first, use the fictional Example Cloud Co. sample built into the page. It has nine POA&M items and three deviation requests, and the walkthrough below uses it.

The converter finds the header row by its column names, so a template with rows above the headers or slightly different column names still works, and you can fix the rest in the next step. It skips the data dictionary and instructions sheets.

Step 2: Verify the import

The second step shows the column map: which spreadsheet column feeds which report field. Required columns are checked first. If a column was not found, pick it from the list or mark it "Not in my file".

This is the mapping, in the order the report fields appear.

The report period comes next. Choose the program, the class, the period start and end, and the package overview URL. Findings detected after the period end are left out, and so are findings closed before the period started. For a historical report, use a workbook exported in that period, because the converter reads each finding's status as it is in the file.

Step 3: Complete the findings

Here is the work the POA&M never asked of you. For each open finding in the period the converter needs four answers, and it links each one to the rule behind it.

The suggestion for the rating is a convenience, not a rule. The POA&M risk column came from scanner severity. The N-rating is about agency impact, which a scanner cannot know. The PAIN rating guide walks through the scale. In short:

• N1: minimal customer effects on one or more agencies
• N2: narrow customer effects on one or more agencies
• N3: a disruptive customer effect on one agency
• N4: a debilitating customer effect on one agency, or a disruptive effect on more than one
• N5: a debilitating customer effect on more than one agency

Findings with the same answers can be completed in bulk. Select them, set reachability, exploitability and the rating once, and the converter applies the answers to the selection.

Two more answers appear only when a finding needs them. A finding listed in CISA's Known Exploited Vulnerabilities catalog needs the catalog due date, because VDR-TFR-KEV applies that date even after mitigation. A finding routed to the Accepted Vulnerability Info needs an acceptance rationale, which the converter prefills from the deviation rationale when there is one.

Step 4: Export and validate

The last step shows both documents, the count of records in each, and the validation result against the two FedRAMP schemas. When every finding is complete and the package overview URL is set, both files download as fedramp-vulnerability-detail-report-<date>.json and fedramp-accepted-vulnerability-info-<date>.json. If something is still missing, the export is labelled a draft, the filename says so, and the review list links to the field that needs an answer.

The gap summary sits under the downloads. One row per finding tells you where each value came from: your answer, a rule default, a suggestion you accepted, a computed value, or a spreadsheet column. It also lists the columns that did not carry over. Download it as CSV and keep it with the report, because an assessor will ask where the N-rating on a finding came from.

Validation is a format check. It proves the JSON matches the schema. It does not prove the evaluations are right. Read the source records and the gap summary before you share the files.

What happens to deviation requests

The three deviation types in the Rev 5 form each have a home in the 2026 reports.

A deviation marked pending, or a request whose status disagrees with the POA&M's own False Positive and Operational Requirement columns, is not decided for you. The converter flags it and asks you to confirm the outcome before it routes the finding.

The CVSS columns on the request form, and the JAB and agency review columns, are not carried over. The 2026 reports have no field for them. They stay in your records and appear in the gap summary. The false positive decisions post and the accepted vulnerability records post cover what assessors expect behind each disposition.

Worked example: Example Cloud Co.

The sample in the converter is a fictional Rev 5 Class C provider. Its POA&M has seven open items and two closed ones. Its deviation form has three requests. The report period is October 1 to November 6, 2026, with the example answers applied. Here is where each item lands.

Six records in the Vulnerability Detail Report, two in the Accepted Vulnerability Info, and both files pass the schema check. This is what V-1002 looks like in the detail report.

{
  "providerTrackingId": "V-1002",
  "detection": {
    "detectedAt": "2026-09-01T00:00:00Z",
    "detectionSource": "Qualys"
  },
  "vulnerabilityDescription": "HTTP/2 Rapid Reset denial of service (CVE-2023-44487). Ingress controller accepts HTTP/2 stream resets without a limit.",
  "evaluationCompletedAt": "2026-09-03T00:00:00Z",
  "isInternetReachable": true,
  "isLikelyExploitable": true,
  "currentRating": 4,
  "projectedNextReduction": {
    "estimatedAt": "2026-10-15T00:00:00Z",
    "targetRating": 0
  },
  "overdueStatus": {
    "isOverdue": true,
    "explanation": "Past the CISA KEV catalog due date of 2026-09-22 (VDR-TFR-KEV)."
  },
  "supplementaryRiskInformation": "Listed in CISA's Known Exploited Vulnerabilities catalog, due 2026-09-22.\nRemediation plan: Upgrade the ingress controller and cap concurrent streams."
}

Two things in that record did not exist in the spreadsheet. The three evaluation fields are the provider's answers. The overdue status is computed from the class, the rating, the two evaluations and the KEV date, using the same arithmetic as the timelines page. A complete example of the whole document is in the Vulnerability Detail Report example.

What does not carry over

Nine POA&M columns have no field in either report: Controls, Asset Identifier, Point of Contact, Resources Required, Planned Milestones, Milestone Changes, Supporting Documents, Service Name, and Weakness Source Identifier. The converter lists them per finding in the gap summary, so nothing is lost silently.

That is by design, not an omission in the schema. The 2026 reports describe the vulnerability and your evaluation of it. Owners, milestones and evidence belong in your own tracking system, where the assessor will look for them under the VDR rules. The VDR vs POA&M post explains the shift from a tracker to a process.

After the conversion

Converting the POA&M once gets you a valid first report. It does not get you compliance, because the report is persistent. Under VER-RPT-PER every report summarizes the activity since the last one, and under VER-TFR-EVU each new finding at Class C must be evaluated within 5 days, 2 days at Class D. Three judgments per finding, on a clock, forever.

Boundera does the persistent part. It connects to the scanners and cloud accounts you already run, proposes the three evaluations with the evidence behind them, computes the deadline for your class, tracks it, and keeps both reports current. If you want to see how the converter's output compares with a live report from your own findings, request a demo. If you want to know where you stand against all 40 VDR and VER rules first, the free gap assessment takes about five minutes.

References

• Free POA&M to FedRAMP Vulnerability Report Converter
• FedRAMP Notice NTC-0014: FedRAMP Response to CISA BOD 26-04
• FedRAMP JSON schemas, including the 2026-06-24 Vulnerability Detail Report and Accepted Vulnerability Info schemas
• FedRAMP 2026 reference: Vulnerability Evaluation and Reporting
• FedRAMP rules on GitHub, the source of the rule text
• FedRAMP Rev 5 documents and templates, for the POA&M template and the deviation request form
• FedRAMP Consolidated Rules 2026 explorer
• VDR and VER timelines by class
• FedRAMP documentation explained: SSP, SAP, SAR and POA&M