Protect Research Notes: Storage, Sharing & Retention

Key takeaways

• 1. Separate observations from secrets
• 2. Restrict the storage and sharing route
• 3. Test the permissions before storing evidence

1. Separate observations from secrets

Create a case folder with three parts: a source log, restricted evidence and a report draft. Give the case an identifier such as CASE-014 rather than naming the folder after a person. In the source log record the public URL, observation time with timezone, the question it answers and whether the observation is confirmed or uncertain. Keep passwords, API keys, recovery codes and session cookies out of all three parts. If a screenshot contains an unrelated email address or browser notification, crop or redact it before sharing. Preserve an unredacted original only when the authorized purpose requires it, in the restricted evidence folder.

2. Restrict the storage and sharing route

Use a device with disk encryption enabled, a screen lock and supported security updates. For cloud notes, choose a workspace you control, enable multifactor authentication, and share with named collaborators rather than an anyone-with-the-link URL. Check whether a shared parent folder gives access to the case automatically. Give report readers access to the report, not the entire evidence directory. Remove collaborators when their work ends. Disk encryption protects a locked device; it does not stop someone reading an unlocked laptop or an already signed-in cloud account.

3. Test the permissions before storing evidence

Create a harmless dummy file first. Copy its sharing link into a signed-out private browser window. If it opens without the intended account, disable public sharing and repeat the check. Then verify that an intended collaborator can open only the agreed files. This is a permission test you can perform with your own workspace, not a claim that MyRecon audits your cloud settings. Include exported PDFs, attachments, local sync folders and downloaded copies in the access review because changing a cloud link does not revoke a copy already downloaded.

4. Use a retention log, including backups

Before collection, write a retention decision: case owner, purpose, review date and deletion trigger. For example, an internal test case might be reviewed 30 days after its report is accepted; that is an illustrative choice, not a legal retention rule. At review, delete unnecessary screenshots, exports and temporary copies. Check the recycle bin, version history, email attachments and backup policy. Record what remains and why. Do not promise immediate erasure from immutable backups; restrict access and allow the documented backup lifecycle to expire copies.

Download the blank register with one illustrative example (CSV)

Worked example: a safe note and a risky note

Risky: a document containing a full copied profile, home address, private guesses and a reusable account token, shared by public link. Safer: CASE-014 / source URL / observed 2026-10-03 14:00 IST / public biography links to the official project / connection unresolved / screenshot stored under restricted evidence / review date assigned. The safer entry retains what supports the question and makes uncertainty visible. Before exporting, search the draft for secrets, hidden comments and identifying filenames, and inspect the export itself. A redaction box that merely covers text is not sufficient if the text can still be selected or copied.

If notes are accidentally exposed

Disable the exposed link, revoke collaborator access where appropriate, and rotate any credentials that appeared in the notes. Establish which files and copies were accessible using the workspace audit features available to you. Notify the responsible project owner through your agreed incident process. Preserve the minimum incident record needed to explain the exposure; copying the entire leaked notebook into more channels creates additional copies. Follow applicable organizational requirements for further response.