How Do You Keep Screenshot Versions and Decision History in Brand-Protection Incidents?
Keep the first screenshot, later observations and review decisions as separate versions under the same brand-protection incident. New information must not overwrite old records. File integrity,…
What’s in this article?
Short answer
Keep the first screenshot, later observations and review decisions as separate versions under the same brand-protection incident. New information must not overwrite old records. File integrity, source and change history must be traceable; technical records must not be confused with sufficient legal evidence.
Observations, files and decisions are different records
An incident’s source may be a listing URL, its attachment a screenshot and its decision a reviewer’s assessment. Keeping all three in one text field makes changes difficult to track. Each observation needs time, source, access context and file identity; each decision needs an owner, rationale and next step.
The seller or product variant may have changed by the next screenshot. Add the new file as a new observation instead of overwriting the old one. If the source is no longer accessible, record that observation state; do not imply the earlier image is current. Filenames can include incident and version identifiers.
Limits of integrity checks
A file hash can technically check whether a stored file has changed. Producing a hash does not itself prove the screenshot was taken at the right time or is sufficient legal evidence. Observation procedure, access authority and any method required by the authorised legal team must be addressed separately.
Restrict access by task. Viewing incidents, adding attachments, changing decisions and exporting files can require separate permissions. Logs may also contain personal data; do not assume unlimited retention. Apply the organisation’s approved retention and disposal plan to the record model.
Make changed decisions traceable
A first review may find suspicion and a later review legitimate use. Rather than deleting the previous decision, add the new rationale and supporting sources. If a platform report was made, mark correction or follow-up separately. Test adding two observations and changing the decision; verify that an authorised user can still trace the first file and decision.
Implementation checklist
- Is observation time separate from the file?
- Does a new file preserve the old version?
- Are the decision rationale and the person responsible recorded?
- Is export permission restricted?
- Are retention and disposal defined for the organisation?
Frequently asked questions
Is a file hash a legal timestamp?
No. Mechanisms serving different purposes must not be presented as one operation.
Should an incorrect decision be deleted entirely?
Preserve change history under correction and retention rules; apply personal-data and disposal obligations separately.
Scope and limitations
This is a proposal for the technical design of records. The organisation’s authorised teams determine a document’s legal evidentiary value, the method of recording observations and the retention period.
Sources and currency
Source review: 7 October 2026. Linked document versions and provider terms may change. Check the current version of the relevant source before implementation.