Evidence assessors accept: build it through the year, not the week before

Assessors accept evidence that was created while the work happened: dated decision records, review minutes, test results and the follow-up that came after them. They distrust folders assembled in the last week, because those show what you wanted to have done, not what you did. The fix is to design your innovation routines so that each one leaves a record by default, then spend the week before an assessment indexing, not inventing.

This applies whether the assessor is a certification auditor for ISO 56001, a government maturity assessor, an internal audit team or a funder reviewing a grant. Each has its own criteria, so always read theirs. The principle underneath is the same.

What assessors are really looking for

An assessor is trying to answer one question: does this organisation do what it says it does, consistently, and does it learn? Three properties make evidence persuasive.

• It is contemporaneous. It carries a date and was made at the time, by the people involved. A meeting note written that afternoon beats a polished summary written six months later.
• It is connected. A policy links to an objective, the objective links to a portfolio decision, the decision links to a project, the project links to a result and a lesson. Isolated documents prove little; a chain proves a system.
• It shows consequence. Something changed because of it: an idea was stopped, a budget moved, a process was revised after a retrospective. Evidence of learning is what separates a working system from a paper one.

What fails: undated slide decks, policies nobody has read, screenshots of a workshop wall with no record of what was decided, and long lists of ideas with no outcomes.

How to build evidence through the year

1. List the claims you will need to support. Start with the assessor's framework, not your filing system. For each criterion, write in one sentence what you claim is true ("we review the innovation portfolio quarterly and record funding decisions"). Keep the list short and honest. Claims you cannot support yet go on a separate list as work to do, not as things to dress up.

2. Attach each claim to a routine that already happens, or should. Evidence should come from work, not from a documentation project. For each claim, name the meeting, review or activity that makes it true. If there is none, you have found a gap in the system, not a gap in the paperwork.

3. Give every routine an owner and a record. Use a RACI to set who runs it and who records it. Decide the minimum record: date, attendees, what was decided, why, and what happens next. A one-page template used every time is worth more than a beautiful one used once.

4. Record decisions, not just activities. "Workshop held" is weak. "Five concepts reviewed; two moved to testing, three stopped because the user interviews did not support the problem" is strong. Portfolio mapping gives you a regular moment to record fund, scale, pause and stop decisions with their reasons.

5. Capture learning while it is fresh. End each project stage with a short retrospective and keep the output. When a test ends, record what you assumed, what you found and what you will do differently. A feedback capture grid is a quick way to log what users told you.

6. Close the loop visibly. When a lesson changes a process, a template or a policy, note the change and link it back to the lesson that caused it. Assessors look for this more than almost anything else, because it is the hardest thing to fake.

7. Keep one index, updated monthly. A single register that lists each claim, the routine behind it, and links to the latest records. Fifteen minutes a month keeps it current. In the week before the assessment, you check the index, fill small gaps and prepare people to talk about their work.

8. Rehearse with people, not documents. Assessors interview. A team lead who can explain why a project was stopped, and what the organisation learned from it, is often stronger evidence than the file itself. Brief people on what the assessor will ask; never script their answers.

Illustrative example: a university in Manchester

Illustrative. A university's research and enterprise office faced its first external review of its innovation programme. The previous year, a similar review had gone badly: staff had spent two weeks building a binder of documents, much of it written for the occasion, and the reviewers had found the dates did not line up with the stories.

This time the office started eleven months out. The head of innovation wrote twelve claims, each tied to an existing routine: the termly portfolio review, the stage-gate meetings for student ventures, the end-of-project retrospectives, the annual policy review. Each routine got a one-page record template and a named recorder. An administrator kept a simple index and checked it on the first Monday of each month.

When the review came, the office had little to prepare. The reviewers asked to follow three projects from idea to outcome, including one that had been stopped. The chain of dated records, plus conversations with the people involved, answered most of their questions. The gaps they did find were real gaps in the system, which the office had already listed as work in progress.

Do's and don'ts

Do

• Start from the assessor's published criteria and read them in full.
• Keep records short, dated and consistent. Consistency is evidence in itself.
• Include stopped projects and failed tests. They show judgement and learning.
• Link evidence to results using a KPI tree, so the assessor can see how activity connects to outcomes.
• Store records where the team works, so creating them is part of the work.

Don't

• Backdate, rewrite or "tidy" historical records. If a record is missing, say so and show what you changed to stop it happening again.
• Build a separate evidence folder that nobody uses between assessments.
• Flood the assessor with volume. Ten connected records beat two hundred loose ones.
• Present photos of sticky notes as evidence of decisions. Record the decision.
• Name or rank individuals in evidence of performance. Show what teams did and decided.

Questions people ask

What counts as evidence in an innovation audit? Dated records that show your system working: decisions with reasons, review minutes, test plans and results, retrospective outputs, and changes made because of lessons. Interviews with the people who did the work count too. Policies alone show intent, not practice.

How far back should our evidence go? Long enough to show a pattern. One cycle of each routine is the minimum; several cycles show consistency. Check the assessor's own rules, since some set a fixed period. For ISO 56001 certification, ask your certification body what they expect at the initial audit.

We have no records from last year. What now? Do not recreate them. Start the routines now, record them properly, and be open with the assessor about when the system began. A short, honest track record with clear improvement is more credible than a long, reconstructed one.

Where to go next

The routines that produce the strongest evidence are the ones covered by our guides to retrospectives, portfolio mapping, RACI and the feedback capture grid. For the wider picture, read our pillar on assessing innovation maturity, and see ISO 56001 vs ISO 56002 if a certification audit is on your horizon.