Patient and member portals: which rule, and who owns conformance
By David LoPresti August 21, 2026 Your organization runs a patient portal, or a member portal, on a platform somebody else built. The vendor has published a conformance report. Your compliance calendar says 11 May 2027. Two questions sit under those facts, and they are answered in different parts of the Code of Federal Regulations: which rule binds the portal, and who is on the hook when a company you pay wrote the code.
Two HHS rules reach the same screen on two clocks, and only one has a date left in the future. The Section 1557 provision on information and communication technology has been enforceable since 5 July 2024, and it names no technical standard, so it tells you the portal must be accessible without telling you what to measure. The Section 504 web and mobile app rule, the one that names WCAG 2.1 Level A and AA, applies from 11 May 2027 for recipients with fifteen or more employees. Under both, the entity that makes the portal available owns the outcome, whoever built it.
One boundary first. Whether your entity receives federal financial assistance within either definition, and what your vendor contract allocates, are questions for your counsel and your contracting team. What follows is the regulatory mechanics and the testing boundary.
The rule that is already in force
45 CFR 92.204(a) reads:
A covered entity must ensure that its health programs and activities provided through information and communication technology are accessible to individuals with disabilities, unless doing so would result in undue financial and administrative burdens or a fundamental alteration in the nature of the health programs or activities.
No date is attached to that sentence. Read as a grace period, the absence is exactly backwards. 45 CFR 92.1(b) provides that “The regulations in this part are effective beginning July 5, 2024, unless otherwise provided in the following schedule,” and Table 1 to Paragraph (b) then names the delayed provisions: 92.7 through 92.11, 92.207(b), and 92.210(b) and (c). Section 92.204 is not in that table, and the part 92 source note records no amendment to it since promulgation.
What counts as information and communication technology is defined rather than argued. 45 CFR 92.4 lists examples including “telehealth interfaces or applications … software; mobile applications; websites; videos; and electronic documents.” A portal is a website, a video visit client is a telehealth interface, and a discharge summary served as a PDF is an electronic document. None of the three waits on a future date.
The limitation is real, though. Section 92.204 names no technical standard, and OCR decided not to add one. In the 2024 final rule OCR recorded that it had “sought comment on whether the section 1557 rule should include a provision requiring covered entities to comply with specific accessibility standards, such as the Web Content Accessibility Guidelines (WCAG)” (89 FR 37522, 37588), and had invited comment “on whether to adopt a safe harbor provision.” It then finalized “the provisions as proposed in Sec. 92.204, without modifications” (89 FR 37522, 37590). Anyone telling you Section 1557 requires WCAG 2.1 of its own force is reading in a requirement OCR declined to write.
There is a bridge, and it reaches further than it first looks. 45 CFR 92.204(b) requires “a recipient or State Exchange” to ensure that health programs provided through websites and mobile applications “comply with the requirements of section 504 of the Rehabilitation Act, as interpreted consistent with title II of the ADA.” Part 92 defines a recipient as an entity “to whom Federal financial assistance is extended directly or indirectly,” and part 92 counts a contract of insurance as that assistance, so the covered entities paragraph (b) does not name are the Department itself and title I entities other than State Exchanges. For everyone else, paragraph (b) opens onto the Section 504 track, which is where WCAG 2.1 lives. What that track carries to an entity that is a recipient under part 92 but not under part 84 is a separate question, and the next section takes it up.
One point to state before a reader meets it elsewhere. A federal court vacated parts of the 2024 Section 1557 rule on 22 October 2025, and HHS published notice at 91 FR 32887 that “The other provisions of the Section 1557 Rule remain in force.” Section 92.204 is not among the eleven vacated provisions, and neither is 92.202.
The rule with a date, and how that date got there
45 CFR 84.84(a) is what your calendar is tracking, and its scoping language is the load-bearing sentence of this article:
A recipient shall ensure that the following are readily accessible to and usable by individuals with disabilities: (1) Web content that a recipient provides or makes available, directly or through contractual, licensing, or other arrangements …
Paragraph (b) supplies the standard and the dates. Beginning 11 May 2027, a recipient with fifteen or more employees must ensure that the web content and mobile apps it provides or makes available, “directly or through contractual, licensing, or other arrangements,” comply with “Level A and Level AA success criteria and conformance requirements specified in WCAG 2.1.” Beginning 10 May 2028, the same reaches a recipient with fewer than fifteen employees. Fifteen, not fifty: HHS OCR’s own Section 504 fact sheet says “recipients with 50 or more employees have until May 11, 2027,” and calls itself “an educational summary, not an independent interpretation of the rule.” Take every date from the CFR.
Those dates are a year later than the ones first promulgated, and the mechanism matters. The extension arrived as an interim final rule, 91 FR 25496, published 11 May 2026 and effective 7 May 2026, with the action line “Interim final rule; request for comments.” HHS wrote that it was needed so recipients would have time to comply “and for the Department to consider whether some of the regulatory provisions could be made less burdensome.” The rule’s DATES section set the comment deadline at 6 July 2026, and the Federal Register’s regulations.gov record for docket HHS-OCR-2026-0133 reported 96 comments when it was last checked on 15 July 2026. A Federal Register API query on RIN 0945-AA30, run 24 August 2026, still returns one document: the interim final rule itself. The date is operative today, and it is not settled. The four dates now on the two federal clocks all arrived the same way.
That is the whole argument for acting now, and it needs no assumption about renewal cycles. Section 84.84(b) bites on a date inside the term of agreements being signed today, and a conformance report obtained before signature can shape the terms. One obtained afterwards can only describe what you already bought.
View the data as a table
| Time | Milestone | Detail |
|---|---|---|
| 7 May 2026 | Rule takes effect | 91 FR 25496 is effective |
| 11 May 2026 | Rule published | Interim final rule |
| 6 July 2026 | Comments close | Deadline set by the rule |
| 15 July 2026 | 96 comments filed | Docket HHS-OCR-2026-0133 |
| 24 August 2026 | Still one document | Under RIN 0945-AA30 |
| 11 May 2027 | Compliance date | Fifteen or more employees |
| Question | 45 CFR 92.204, Section 1557 ICT | 45 CFR 84.84, Section 504 web and mobile | 28 CFR 35.200, ADA Title II web and mobile |
|---|---|---|---|
| Who is bound | ”A covered entity”: a recipient of federal financial assistance, the Department, or a title I entity (45 CFR 92.2(a), 92.4) | “A recipient” of HHS federal financial assistance (45 CFR 84.84(a)) | “A public entity” (28 CFR 35.200(a)) |
| Does a contract of insurance count as the funding hook | Yes. Federal financial assistance includes “a contract of insurance,” plus advance premium tax credit and cost-sharing reduction payments (45 CFR 92.4) | No. The definition excludes “a direct Federal procurement contract or a contract of insurance or guaranty” (45 CFR 84.10) | Not applicable. Coverage runs by entity type, not by funding |
| Technical standard | None. OCR sought comment on adopting WCAG and a safe harbor, then finalized 92.204 “without modifications” (89 FR 37522, 37590) | WCAG 2.1 Level A and AA, the W3C Recommendation of 05 June 2018, incorporated by reference (45 CFR 84.84(b)) | WCAG 2.1 Level A and AA, the same 2018 document (28 CFR 35.200(b)) |
| In force from | 5 July 2024. Not listed in Table 1 to 45 CFR 92.1(b) | 11 May 2027 at fifteen or more employees; 10 May 2028 below that | 26 April 2027 at population 50,000 or more; 26 April 2028 below that or for a special district government |
| How the current dates were set | Unchanged since promulgation | Interim final rule, 91 FR 25496, effective 7 May 2026 | Interim final rule, 91 FR 20902, effective 20 April 2026 |
| Reaches content supplied under contract | Yes, by cross-reference (45 CFR 92.101(b)(1)(i) and 92.202(a)) | Yes, in the section’s own text | Yes, in the section’s own text |
Whether either rule reaches you is an entity-specific test
Neither rule covers hospitals as a class or insurers as a class. Each covers entities that meet a funding test, and the two tests part company in one place. Both parts define a recipient in near-identical terms, as an entity to which federal financial assistance “is extended directly or indirectly” (45 CFR 92.4) or “is extended directly or through another recipient” (45 CFR 84.10). The divergence is in what counts as that assistance. Part 92 defines it as “any grant, loan, credit, subsidy, contract (other than a procurement contract but including a contract of insurance), or any other arrangement,” and adds “advance payments of the premium tax credit and cost-sharing reduction payments under title I of the ACA.” Part 84 excludes exactly what part 92 includes: “any grant, cooperative agreement, loan, contract (other than a direct Federal procurement contract or a contract of insurance or guaranty), subgrant, contract under a grant or any other arrangement.”
Read those side by side and one entity lands on both sides of the line. An issuer whose only federal nexus is a contract of insurance is a recipient under part 92, so 92.204(b) fires and puts its websites and mobile applications onto the Section 504 track. The same issuer is not a recipient under part 84, so 84.84(b), which binds “a recipient” as part 84 defines that word, does not reach it in its own terms. Whether the “requirements of section 504” that 92.204(b) imports carry 84.84’s dated WCAG 2.1 obligation that far is not resolved by any source found in this research. An entity taking HHS grant money has no such question: it is a recipient under both parts. The answer changes by legal entity, not by industry, which is why a healthcare organization with several affiliated corporations can hold two answers inside one brand.
View the data as a table
| 45 CFR part 92 (Section 1557) | 45 CFR part 84 (Section 504) | |
|---|---|---|
| How a recipient is defined | An entity to which assistance “is extended directly or indirectly” | An entity to which assistance “is extended directly or through another recipient” |
| Whether a contract of insurance counts | Included: “contract (other than a procurement contract but including a contract of insurance)“ | Excluded: “a direct Federal procurement contract or a contract of insurance or guaranty” |
| An issuer whose only nexus is insurance | A recipient, so 92.204(b) fires and puts its websites onto the Section 504 track | Not a recipient, so 84.84(b) does not reach it in its own terms |
| An entity taking HHS grant money | A recipient under both parts | A recipient under both parts |
Nobody can delegate this, and HHS said so in terms
The most useful sentence written about portal ownership is not in the rule text. It is in the preamble to the 2024 Section 504 final rule, responding to comments on 84.84 at 89 FR 40066, 40129:
As the Department made clear in the preamble of the proposed rule, its intent is that websites operated on behalf of a recipient by a third party be covered by the rule. … These edits will dispel any doubt that recipients cannot delegate away their obligations under section 504.
Further on, OCR closes the ownership argument too: “provides or makes available” is “not intended to mean that Sec. 84.84 only applies where the recipient created or owns the web content or mobile app,” because “The plain meaning of ‘make available’ includes situations where a recipient relies on a third party to operate or furnish content.”
Section 1557 reaches the same place by a different road, and the road is worth walking because a careless citation here is easy to rebut. The phrase “directly or through contractual, licensing, or other arrangements” does not appear anywhere in 45 CFR part 92. It arrives by cross-reference, twice. 45 CFR 92.101(b)(1)(i) requires a recipient and State Exchange to comply with “the Department’s implementing regulations for … section 504 … found at 45 CFR parts 80, 84, 86 (subparts C and D), and 91 (subpart B),” and the Section 504 general prohibition in that set, at 45 CFR 84.68(b)(1), bars a recipient from discriminating “directly or through contractual, licensing, or other arrangements.” Separately, 45 CFR 92.202(a) requires effective communication “in accordance with the standards found at 28 CFR 35.130 and 35.160 through 35.164,” with “covered entity” substituted for “public entity,” and 28 CFR 35.130(b)(1) carries the same phrase. Cite 92.101 with the subparagraph: 92.101(a)(2)(iv) was vacated, and 92.101(b)(1)(i) was not.
OCR was asked to bless the vendor report as the way to discharge this, and declined. One group asked OCR to clarify “that third-party providers of ICT are not directly covered by this regulation,” and several commenters suggested that a Voluntary Product Accessibility Template “should be completed by the third-party vendors.” OCR’s response, at 89 FR 37522, 37589, opens:
Regardless of the method that a covered entity uses to acquire ICT, the health programs and activities it provides through that ICT must be accessible to individuals with disabilities.
The rest of the response says that OCR “will continue to closely monitor this area” and points to the Section 504 and Title II web rulemakings, which “provide greater clarity on obligations to ensure that web content and mobile applications are accessible.” Asked about VPATs, OCR pointed at the rules rather than at the template. Nothing there endorses the VPAT, requires one, or says that holding a vendor report discharges anything.
The portal, layer by layer
A hosted portal is not one artifact. Splitting it into layers shows which parts a product-level vendor report could speak for even in principle. The model below is an analytical construction from the definitions and examples in the two rules, not an industry standard architecture. No source found in this research publishes one.
| Layer | Rule text that reaches it | What a product-level vendor report can speak for |
|---|---|---|
| Vendor-shipped portal UI, as delivered | 45 CFR 84.84(a)(1), web content a recipient “provides or makes available, directly or through contractual, licensing, or other arrangements”; 45 CFR 92.4, ICT includes websites | The product as tested, at a stated version. Where the product has no URI before installation, WCAG 2.1 contemplates only “a statement that the product would conform when installed” |
| Tenant configuration and theming | Same. 84.84 turns on “provides or makes available,” and OCR says the phrase does not limit the rule to content the recipient created or owns | Nothing. The configured instance is not the tested artifact |
| Forms and questionnaires built by the tenant | 45 CFR 84.10 defines web content to include “code or markup that defines the content’s structure, presentation, and interactions” | Nothing about the instrument. At most, the authoring tool |
| Documents generated for a named patient or member | 45 CFR 84.85(d) excepts conventional electronic documents that are “About a specific individual, their property, or their account” and “Password-protected or otherwise secured” | Nothing. Documents are content, not product |
| Public-side documents, for example a price list or a downloadable form | 84.85(d) does not apply. OCR: documents “on a recipient’s general, public web platform would not be covered by the exception” | Nothing |
| Embedded scheduling and payment | 45 CFR 84.85(c) excepts third-party content “unless the third party is posting due to contractual, licensing, or other arrangements with the recipient” | Only that component’s own report, at its own version |
| Video visit client | 45 CFR 92.4 names “telehealth interfaces or applications” as ICT | The client software as tested. Not the interpreter workflow, which is an operational matter |
Two rows deserve more than a cell. The password-protected document exception at 45 CFR 84.85(d) is narrower than it looks: it reaches conventional electronic documents, an exhaustive list of four formats under 45 CFR 84.10, and not the interface that serves them. Even inside the exception, OCR wrote at 89 FR 40066, 40151 that “the existing section 504 obligations require recipients to furnish appropriate auxiliary aids and services where necessary,” which “could include, for example, providing PDFs that are accessible.” A secured lab result is excepted from the technical standard, not from Section 504.
The embedded payment step invites the opposite error. HHS’s fact sheet is direct: “Where, for example, the recipient links to online payment processing websites offered by third parties to accept the payment of fees … the exception does not apply.” A payment vendor you contracted with is not an unaffiliated third party posting on your page.
What a conformance report can and cannot speak for
WCAG 2.1 sets its own rules about what a claim covers, and 84.84(b) makes those rules binding by incorporating the “success criteria and conformance requirements specified in WCAG 2.1,” not the criteria alone. Section 5.2.2 states that “Conformance (and conformance level) is for full Web page(s) only, and cannot be achieved if part of a Web page is excluded.” Section 5.2.3 goes further:
When a Web page is one of a series of Web pages presenting a process … all Web pages in the process conform at the specified level or better.
That dissolves the module-by-module report. Register, verify identity, schedule, complete an intake questionnaire, pay a copay: if the scheduling module conforms and the payment step does not, the process does not conform, and 84.84 is written against what the recipient makes available rather than against modules.
Section 5.3.1 lists the five components a conformance claim must contain, including “A concise description of the Web pages, such as a list of URIs for which the claim is made.” Its note draws the vendor and tenant boundary: “Web-based products that do not have a URI prior to installation on the customer’s Web site may have a statement that the product would conform when installed.” That is what a hosted portal vendor can claim before your instance exists: a statement about a product, conditioned on installation. Your instance is the installation.
Section 5.4 offers a statement of partial conformance for pages carrying content the author does not control, and it names a portal among its own examples. Its options are a determination based on best knowledge, available only where non-conforming content is “monitored and repaired … within two business days,” or a statement that the page “does not conform, but would conform to WCAG 2.1 at level X if the following parts from uncontrolled sources were removed.” Those parts must be “not content that is under the author’s control,” and no source found in this research states whether vendor-supplied portal code meets that test. The route out is closed from the regulation’s side rather than WCAG’s: 84.84(b) requires compliance with the conformance requirements, and a statement of partial conformance is not a way of satisfying them. It is a way of describing a page that does not.
View the data as a list
A WCAG 2.1 conformance claim: 84.84(b) incorporates the conformance requirements, not the criteria alone
- 5.2.2 Full pages only: Cannot be achieved if part of a Web page is excluded
- 5.2.3 Complete processes: All Web pages in the process conform at the specified level or better
- 5.3.1 A named list of URIs: No URI before installation means only a statement about the product
- 5.4 Partial conformance: Describes a page that does not conform. Not a way of satisfying 84.84(b)
Federal procurement guidance, written for a different audience, is blunt about the weak cells in a report. GSA states that a note of “not evaluated” means “the vendor has not conducted an assessment” and “does not provide any assurance of accessibility,” and that “partially supports” means “the product does not conform to Section 508 standards.” GSA also advises that “Whenever possible, purchasers should conduct independent conformance validation testing and evaluation to verify vendor accessibility conformance claims.”
Name the edition, and ask about 4.1.1
GSA writes about reports keyed to the Revised 508 Standards, which sit on WCAG 2.0, while a recipient under 84.84(b) is bound to WCAG 2.1. ITI publishes four editions, and its own page gives two accounts of them. The edition list says the WCAG edition covers “WCAG 2.0 or ISO/IEC 40500 (equivalent to WCAG 2.0), WCAG2.1, and WCAG 2.2” and that the INT edition “Incorporates all three of the above standards.” A summary list further down says only that “WCAG 2.1 is incorporated into the EU edition” and “WCAG 2.2 is incorporated into the WCAG and INT editions.” Three of the four editions carry WCAG 2.1 criteria on the first reading and one does on the second. Take the edition list, which is the more specific of the two, and the ask is the WCAG edition with its WCAG 2.1 columns completed rather than “a VPAT,” since no edition is keyed to WCAG 2.1 alone. ITI is also clear about what the template is not: “No, ITI does not review or approve VPATs,” and “There is no submission process for the VPAT.” Our VPAT and ACR work starts there, and the version-by-rule matrix is what to hand a vendor who asks which edition you want.
HHS supplies an escape hatch that leaves one loose end. 45 CFR 84.87 permits alternatives that “result in substantially equivalent or greater accessibility and usability,” and the 2024 preamble applies it to the next WCAG version: “Recipients could also choose to comply with this rule by conforming their web content to WCAG 2.2 Level AA … because WCAG 2.2 Level AA provides substantially equivalent or greater accessibility and usability to WCAG 2.1 Level AA” (89 FR 40066, 40155). The same passage names the loose end in passing: WCAG 2.2 Level AA includes every WCAG 2.1 Level AA criterion “with the exception of one success criterion that is obsolete.” WCAG 2.2 identifies it: “WCAG 2.2 has removed one success criterion, 4.1.1 Parsing,” and authors “required by policy to conform with WCAG 2.0 or 2.1 … may need to continue to test and report 4.1.1.” A WCAG 2.2 report is silent on a Level A criterion inside the version the CFR incorporates. Ask for it in writing.
What to ask a portal vendor for
No HHS rule tells a recipient what to require from a vendor. Part 84 and part 92 are silent on conformance reports, and a text scan of the 2024 Section 504 preamble returns zero occurrences of “VPAT,” zero of “Voluntary Product” and zero of “conformance report.” The only federal artifact guidance is GSA’s, written for federal agencies buying under Section 508. It does not bind an HHS recipient. It is a borrowable pattern, and the best one that exists.
View the data as a table
| What it settles | What it does not settle | |
|---|---|---|
| An ACR, with the edition named, and 4.1.1 Parsing reported | Which version and level the vendor tested against, and the per-criterion result | Whether your tenant instance conforms |
| The evaluation method behind the report | Whether anyone tested with assistive technology, and how much of the product | Anything about your configuration |
| A named list of core functions that cannot be used | The known failures, in plain language rather than as “partially supports” | Whether a failure sits on a step of a process you rely on |
| Configuration and installation guidance for accessibility | Which switches you have to set, since the tenant owns configuration | Whether you set them |
| The scope statement: which URLs, flows and screen sizes | Whether the claim covers a complete process rather than a module | Anything about content you upload |
Four of those five asks are the contents of the Supplemental Accessibility Report in GSA’s request pattern: the evaluation methods, the accessibility features, “Information on core functions that can’t be used by persons with disabilities,” and “Information on how to configure and install the ICT item to support accessibility.” A separate block on the same page, for commercial items “that will be configured or modified to meet contract requirements,” asks the offeror “to demonstrate how they will configure or maintain the solution.” The fifth comes from WCAG 2.1 section 5.3.1. Two expected items are absent on purpose: no published source found in this research states how old a report may be before it is stale, and none states a required test sample size.
The payer surfaces are the same analysis on different screens
A plan finder, a provider directory, a formulary lookup and a prior authorization flow raise the same ownership question, and a Medicaid managed care plan is already under a dated standard. 42 CFR 438.10(a) defines “readily accessible” as “electronic information and services which comply with modern accessibility standards such as section 508 guidelines, section 504 of the Rehabilitation Act, and W3C’s Web Content Accessibility Guidelines (WCAG) 2.0 AA and successor versions.” Paragraph (c)(1) applies that to enrollee information from states, MCOs, PIHPs, PAHPs, PCCMs and PCCM entities, (c)(5) puts the state under a duty to ensure it “through its contracts,” and (h) and (i) place the provider directory and the formulary inside the required information. No future date is attached. On the Exchange side, 45 CFR 155.205(c)(1) requires information to be accessible to “Individuals living with disabilities including accessible Web sites and the provision of auxiliary aids and services at no cost to the individual in accordance with the Americans with Disabilities Act and section 504 of the Rehabilitation Act,” naming no WCAG version.
Two cautions. 45 CFR 156.230(b)(2)(i) provides that a provider directory is easily accessible when the general public can view all of a plan’s current providers on the issuer’s public website “through a clearly identifiable link or tab and without creating or accessing an account or entering a policy number,” and 45 CFR 156.122(d)(1)(i) sets the same test for a formulary drug list. That is a findability rule, not a disability accessibility rule, and citing it as one is an error a knowledgeable reader will catch. And no provision found in this research names an accessibility standard for a prior authorization interface as such: that surface reaches the rules only through 92.204(a), 84.84(a), and 438.10(c)(1) where Medicaid managed care applies. For an issuer or other financial services organization building one, the obligation is real and the yardstick comes from the general rules.
What is not decided
No court has applied any of these provisions. A CourtListener opinion search run on 24 August 2026 returns zero published opinions citing 45 CFR 84.84, zero citing 45 CFR 92.204 and zero citing 28 CFR 35.200, in both the “45 CFR” and “45 C.F.R. §” forms. A control query for 45 C.F.R. § 92.101 returns two results, which confirms the query form and the index work. The claim is scoped to that database and that date.
OCR was asked about authenticated portal workflows and answered about documents. A commenter on the Section 504 rule asked whether recipients “would need to make any workflow undertaken by a patient after authenticating such as when a patient uses a patient portal to schedule an appointment with their provider” accessible. OCR’s response at 89 FR 40066, 40151 addresses the document exception and discusses PDFs. It never reaches the authenticated workflow. The scoping language at 84.84(a) covers web content the recipient makes available, and an authenticated scheduling flow is web content. But the question was asked and was not answered.
Section 92.204’s bridge has an unmarked end. Take a covered entity that is a recipient under part 92 but not under part 84. An issuer whose only federal nexus is a contract of insurance is the clean case. Paragraph 92.204(b) imports “the requirements of section 504,” and no source found in this research says whether those requirements carry 84.84’s WCAG 2.1 obligation to an entity that part 84 does not define as a recipient. For the Department and for title I entities other than State Exchanges, paragraph (b) does not apply at all and no rule names a target.
The compliance dates rest on an open comment record. DOJ is in the same posture on the Title II side. Part 84 is separately under proposed amendment at 90 FR 59478, with comments reopened at 91 FR 4467, but those proposals address 45 CFR 84.4(g) and the definition of disability, not the web subpart.
Where this stops
An accessibility evaluation can tell you what your deployed portal instance does against WCAG 2.1 Level A and AA, which layers fail, and whether a complete process such as register, schedule, intake and pay conforms end to end. That is testable and it has an answer.
It cannot tell you which of your legal entities receives federal financial assistance within 45 CFR 92.4 or 45 CFR 84.10, and it cannot rewrite a signed master services agreement. Those belong to your counsel and your contracting team. What testing gives both of them is the one thing a vendor report does not contain: a record of what your instance does, on your configuration, with your content in it.