You can reuse an evaluation as far as its recorded scope reaches, and no further. That is the whole rule. The date on the cover is the thing everybody looks at and the thing that decides least, because no accessibility document has an expiry and no standard sets one.
The two questions that settle it
What did the evaluation actually cover, and what is this recipient asking for? If the second sits inside the first, you can reuse it. If it does not, no amount of recency helps.
Reuse Follows the Scope, Not the Date
A useful report records its scope, its structured sample, its random sample and how that was picked, and the complete processes it followed end to end. Those four items are required by W3C's method and they are the four commercial reports most often leave out, which is exactly why so many owners cannot answer the reuse question about their own document.
So the first move is to read your own report for what it says it covered. If it names templates and journeys, you know where reuse stops. If it names a page count and a date, you have a document that will be reused wrongly by somebody in your sales team within a month.
| What changed | Can the existing evidence answer? | What to do |
|---|---|---|
| A new customer, same product, same version | Yes, if their ask sits inside your evaluated scope | Send it, and say what the scope was rather than letting them assume |
| They asked for a different standard or edition | Partly. The findings hold; the rows change | Map the existing findings onto the requested edition and check which criteria have no evidence |
| You shipped a release that touched the interface | Not for the parts that changed | Retest what changed, then update the report and say what was revisited |
| A whole new product or a new tenant configuration | No | That is a different evaluation, whatever the shared codebase suggests |
| The contract is up for renewal and nothing shipped | Yes, and say so plainly | Send the same evidence with a change log showing what did not change |
One Report Can Cover Several Components
A common worry is that a platform, its mobile app and its documentation each need their own conformance report. They do not. Federal guidance answers this directly: one report may address all the relevant standards and criteria that match your product's functionality, and separate reports are an option rather than a duty.
The same guidance draws the line for add-ons. If you built it, you report on it, even where it plugs into somebody else's product. Which is the sensible answer, because you are the only party who can test it.
What Triggers a New One
The trigger is a change to the product, not a date in the calendar. Federal guidance puts it as a may, deliberately: every time the product changes, an updated report may be required to address any change in its accessibility. A typo fix in a footer is not that. A rebuilt checkout is.
You will see an annual refresh recommended in various places, including on our own VPAT page, which we are correcting. Nothing in the template, in ITI's guidance or in federal guidance sets an interval. What a recipient's own policy sets is a different matter and it binds their suppliers, which may include you.
A New Date Is Not a New Evaluation
The conformance template requires a report date, meaning the date of publication, and it has no field for the date of testing. So from outside, a refreshed cover and a fresh evaluation are indistinguishable. The only guidance on revisions is to change the date and explain the revision in the notes, and it is guidance rather than a requirement.
Which means the notes field is where your credibility lives. Write what was revisited and when. A buyer who sees that will trust the rest of the document more, and a buyer who sees a bare new date will wonder, correctly, whether anything happened.
The Renewal Conversation
At renewal, the customer is usually not asking whether your document is old. They are asking what has changed since they last looked. So lead with the change log and let the evidence follow it.
ITI concedes the underlying difficulty in its own guidance, noting that software delivered continuously, on cycles of weeks or days, poses a real challenge for assessing conformance. Quoting that is more useful than pretending your quarterly releases have not moved anything, and it sets up the honest version of the conversation: here is what we retested, here is what we did not, here is when we will.
What Cannot Be Reused
- Anything the evaluation did not reach. It was never used once, so there is nothing to reuse. Untested is a status, and it stays that way until somebody tests it.
- A whole-site conclusion drawn from a sample. A sampled evaluation cannot support a conformance claim for an entire site, because an unexamined page may carry an error, and that holds however large the sample was.
- A base product's evidence, for a configured instance. Themes, flags, plugins and your customer's own content are outside what a base evaluation looked at.
- Somebody else's report. A reseller may complete a conformance report, so the document in your hand was not necessarily written by anyone with the source code.
Everything else stretches further than most people expect, provided the report wrote down what it did. Which is the argument for insisting on those four scope items when you write the audit brief, rather than discovering their absence when the third customer asks.