The problem in plain language
During an audit or control review, teams collect screenshots from admin consoles, spreadsheets, ticketing systems and application settings. The files are then placed in folders or attached to workpapers. Months later, someone has to work out what each image represented, which system produced it, whether the configuration has changed and how the evidence connects to the control being assessed.
The same exercise is then repeated next cycle, often by different people, because the previous screenshots cannot be refreshed—only replaced. Evidence collection becomes a seasonal scramble rather than a by-product of how the business already runs its systems.
What the buyer is actually trying to solve
The buyer needs compliance evidence that is attributable, repeatable and connected to the assessment decision—not merely a collection of images that looked persuasive at one point in time. In practice the search language is closer to “audit evidence collection takes too long”, “how to automate compliance evidence”, “continuous control monitoring” or “auditor rejected our screenshots”. Behind each phrase is the same need: to show, with confidence and without heroics, that a control operated as intended.
Evidence and system mechanism
NIST SP 800-53A Rev. 5 provides a methodology and set of procedures for assessing security and privacy controls, executed at various phases of the system development life cycle and tailorable to the organisation. Its approach centres on defined assessment procedures applied to assessment objects, rather than on whatever artefact happens to be to hand.
NIST's OSCAL Assessment Results model goes further by representing assessment results in structured, machine-readable XML, JSON and YAML. It distinguishes an assessment log of performed actions with start and end timestamps, observations with related evidence of compliance or non-compliance, risks, findings that can include control objective status, and back matter for attachments and citations. That structure is a useful reference model even for organisations that never adopt OSCAL itself: it shows which relationships a durable evidence record needs to preserve.
NIST SP 800-137, on information security continuous monitoring, describes the aim of ongoing visibility into assets, threats and vulnerabilities, and into the effectiveness of deployed controls—ongoing assurance rather than a periodic snapshot.
Neither source says screenshots are inherently invalid. The operational issue appears when screenshots become the primary evidence system and are detached from source identifiers, collection method, timestamps, control objectives and durable assessment records.
Why screenshots make weak primary records
- They capture a view, not a record. A screenshot shows what was on screen, filtered by whatever the person had selected. It does not show what was excluded.
- Provenance is implicit. The system, tenant, environment, account and time are often inferred from file names or folder locations, if they are recorded at all.
- They cannot be re-run. When a reviewer asks a follow-up question, the only option is to take another screenshot, which shows a different moment.
- They do not scale. Population-based evidence—every leaver, every privileged account, every change—cannot sensibly be captured as images.
- They hide drift. A configuration captured once says nothing about whether it held between assessments.
Illustrative example. A hypothetical company evidences its multi-factor authentication control each year with a screenshot of a policy settings page. The image shows the policy enabled. It does not show which users or groups the policy excluded, when it was enabled, or whether it was briefly disabled during a migration. A query or export from the identity platform, recorded with its parameters and collection time and linked to the control, would answer those questions—and could be re-run next quarter.
Problem owner and why now
Compliance, security assurance, risk and control owners carry the operating problem. System administrators carry much of the collection burden. Urgency rises around audits, customer assurance requests, regulatory reviews, certifications and repeated control testing—especially when the same evidence has to be reconstructed each cycle. It also rises when the business adds frameworks or customers, because each new request multiplies the volume of manually gathered artefacts.
Warning signs
- Evidence folders are organised by audit year rather than by control.
- Reviewers ask “where did this come from?” and the answer depends on one person's memory.
- The same administrator is pulled off operational work every audit season.
- Evidence for population-based controls is a handful of example screenshots.
- Findings recur because remediation is not linked back to the evidence that exposed the gap.
Economic consequence
Weak evidence operations consume specialist time, slow reviews and create uncertainty about whether a control was actually tested against the intended source. They also tie assurance capacity to a few individuals, which becomes a risk when those people leave. The useful measures are evidence-collection effort, repeated manual retrieval, unresolved provenance questions, stale artefacts and the number of controls whose evidence cannot be reproduced from the source system.
Root cause
The root cause is often that evidence collection was designed as a document-gathering exercise rather than an information lifecycle. There is no durable link between control, assessment procedure, source system, observation, artefact, owner and review outcome. Screenshots fill the gap because they are the easiest artefact to produce without that structure.
Practical intervention
- Define what evidence is required for each control and assessment objective.
- Record source system, query or collection method, timestamp and responsible owner.
- Prefer direct reports, exported records, logs or machine-readable evidence where those better preserve provenance.
- Use screenshots selectively when visual state is genuinely relevant, and attach sufficient context to reproduce the observation.
- Connect artefacts to the control, assessment step, finding and review decision.
- Automate repeatable evidence collection where the underlying system supports it.
- Retain evidence according to the organisation's control and records requirements.
A sensible starting point is the small set of controls that consume the most collection effort or produce the most reviewer questions. Similar record-keeping principles apply elsewhere in compliance operations; see why policy acknowledgements need a reliable system record and why application risk assessments cannot be one-time.
Trade-offs
Automated evidence collection requires integration work, API access and someone to maintain the collectors when source systems change. Machine-readable formats help reuse but may not be what a particular auditor asks for, so the evidence system should be able to produce human-readable outputs too. Some systems offer no export or API, and a well-annotated screenshot remains the practical choice. The goal is not to eliminate screenshots; it is to stop them being the only thread connecting a control to its proof.
Diagnostic questions
- Can an assessor reproduce the observation from the original system?
- Does every artefact identify what control and assessment step it supports?
- Can reviewers tell when and how evidence was collected?
- Which evidence is repeatedly gathered by hand each cycle?
- Are screenshots being used because they are appropriate, or because no evidence pipeline exists?
- Could you show that a control held between assessments, not just on the day of collection?
What good looks like
Evidence has provenance. Observations can be linked back to systems and assessment procedures, recurring evidence is collected consistently, artefacts carry enough context for independent review and screenshots are one evidence type rather than the compliance operating model. Audit preparation becomes a review of evidence that already exists, not a hunt for it.
Where Mellorca fits
Mellorca can map compliance evidence workflows, connect source systems to control records, automate recurring evidence collection, design structured evidence repositories and improve the operational traceability between controls, observations and remediation. A Digital Systems Audit is often the right first step to identify which systems can supply evidence directly.
Method note
This article does not claim that screenshots are unacceptable evidence. Evidence sufficiency depends on the applicable control framework, auditor and context. The example is illustrative rather than a client case. The focus is the operational weakness created when screenshots cannot be tied to reproducible source observations and durable assessment records.
Sources and further reading
- SP 800-53A Rev. 5, Assessing Security and Privacy Controls in Information Systems and Organizations - CSRC (last verified 10 October 2026)
- Assessment Results Model (last verified 10 October 2026)