Evidence reviewer

evidence-reviewer

Review a finished compliance deliverable the way a careful senior reviewer would, before it reaches the auditor or the client. This is a methodology skill: you read the document and apply the checks below. There is no script to run.

Works on any deliverable type: gap assessments, readiness reports, policies, vendor assessments, questionnaire answers, evidence packages, screenshots, status reports. Checks are feature-triggered. Apply a check only when the document actually contains that feature (a document with no findings table skips the finding-language checks; a document with no images skips screenshot hygiene).

Workflow

1. Identify the deliverable, the intended recipient (the auditor, the client, or internal), and the framework in scope (SOC 2, ISO 27001, ISO 42001, HIPAA, GDPR, PCI DSS, or another named framework). Ask if unclear.
2. Read the whole document. Then apply each check area below where its feature is present. Keep a running list of findings with exact locations.
3. Report a findings table, then a verdict. Never silently rewrite the document. Offer fixes; let the Consultant decide.

Check areas

1. Language, formatting, and completeness

Check only prose the author wrote. Do not flag verbatim quoted framework text (quoted ISO clauses, AICPA criteria, regulation excerpts). In assessment deliverables that quoted text is often half the document and cannot be changed.

• Spelling, wrong-word errors (their/there, ensure/insure), subject-verb agreement, tense drift, run-on sentences, sentence fragments.
• Truncated content: sentences or table cells that end mid-thought, half-filled tables, sections with a heading but no body, numbered lists that skip entries.
• Structural formatting: broken heading hierarchy, inconsistent list style, tables with misaligned or missing columns, broken links and cross-references.
• Consistent spelling variant throughout (do not mix US and British spelling; ISO-aligned documents conventionally use Oxford spelling).

2. Terminology and control-ID validity

• Correct framework names and formats: "SOC 2" not "SOC2" or "SOC-2", "SOC 2 Type II" not "Type 2", "ISO 27001" or "ISO/IEC 27001:2022", "ISO/IEC 42001:2023". Type I is design at a point in time; Type II is operating effectiveness over a period. Flag any mix-up.
• Correct management-system term for the framework: ISO 27001 has an ISMS, ISO 42001 has an AIMS. "ISMS" in an ISO 42001 report is a real and common error. Flag it.
• Control and clause ID validity: every cited ID must exist in the named framework. SOC 2 common criteria run CC1 through CC9; a "CC11.2" does not exist. ISO 27001:2022 Annex A controls run A.5 through A.8. ISO clause references do not take a "C." prefix (write "Clause 9.3.1", not "Clause C.9.3.1"). HIPAA citations follow 45 CFR 164.xxx. If you are not certain an ID exists, say so rather than guessing.
• Consistent capitalization of product and proper nouns throughout.

3. Confidentiality leakage

The highest-stakes area. A single leak can end a client relationship.

• Other companies' names: any organization named that is not the client, the client's own vendors/customers, or the framework body. A stray name from another engagement is a blocker. The client's own customers and vendors named as evidence are legitimate; when the relationship is unclear, raise a major finding asking the Consultant to confirm rather than assuming.
• Unredacted personal data: names, emails, or IDs of individuals who are not relevant signatories or owners; anything resembling government IDs or health data.
• Secrets and credentials: API keys, tokens, passwords, private key blocks, connection strings, in prose or visible in screenshots.
• Placeholder and draft residue: TODO, TBD, TBC, FIXME, [CLIENT], [COMPANY NAME], {{merge_field}}, <<placeholder>>, lorem ipsum, "DRAFT", "do not distribute", tracked changes or comments left in the file.
• Document metadata: author, title, company, and template fields in file properties that expose a different organization or the template's origin.

4. Finding language quality

Applies when the deliverable contains findings, gaps, or nonconformities.

• A finding states an observed condition, which is the negation of the desired control state. The control name describes the desired state ("MFA is enforced on all administrative accounts"); the finding must state the gap ("MFA is not enforced on 4 of 12 administrative accounts"). Flag findings that merely restate the control name or are written in desired-state voice.
• Each finding carries the gap, why it matters, and the evidence examined or missing. Flag findings that assert a gap with no stated basis.
• Remediation actions name the evidence artifact that will close the gap and how it will be verified ("export the Q2 access review and have the reviewer sign off; the auditor re-performs on a sample"), not vague advice ("improve access reviews").
• A "needs evidence" state in a monitoring tool is not by itself a control gap. Flag findings that appear to be raised straight from a tool status without confirming the control is actually deficient.

5. Screenshot and evidence hygiene

Applies when the package contains screenshots or exported evidence.

• A timestamp or date is visible, and it falls inside the audit period.
• The system is identifiable: a URL, window title, or banner shows which tool the screenshot came from.
• The screenshot shows what the evidence request asked for, not an adjacent screen.
• Nothing unrelated or sensitive is in frame: other browser tabs, chat or email notifications, bookmarks, other customers' records, credentials.
• Exports state their source and generation date, and population listings are complete rather than visibly cut off.

Output format

Report all findings in one table, ordered by severity:

Severity	Location	Issue	Suggested fix
blocker	Section 3, finding table row 2	Names an unrelated company	Remove or replace with the correct entity
major	Section 5.1	"CC11.2" is not a SOC 2 criterion	Confirm the intended criterion (CC1 to CC9 exist)
minor	Executive summary, para 2	"Soc2"	"SOC 2"

Severity definitions:

• blocker: do not send. Cross-organization leakage, secrets or personal data, placeholder or draft residue, wrong client, fabricated or invalid control citation presented as fact.
• major: fix before sending. Wrong terminology, invalid or unverifiable control ID, truncated content, finding that does not state an observed condition, remediation with no artifact or test, screenshot outside the audit period, metadata exposure.
• minor: fix if time allows. Typos, inconsistent capitalization, formatting and style issues.

Close with a one-line verdict: Pass (zero blockers and zero majors) or Needs changes (anything else), plus a one-sentence summary of what stands between the document and Pass. Do not soften the verdict; an unresolved blocker is always Needs changes.

A condensed one-page version of these checks is in checklist.md for quick pre-send passes.

Related skills

• soc2-advisor
• hipaa-advisor
• compliance-calendar
• gap-assessment