Changing a parental control is easy; proving what changed and whether it worked is the harder part. Keep enough evidence to identify the affected account and device, reconstruct the old and new rule, and test the result. Do not capture passwords, access codes, private messages, browsing history, or unrelated information about the child.
Record the scope before the change
Write down the date and time, the adult account that is authorized to manage the controls, the child's account, and the device or platform affected. Use a masked account identifier when a full email address is unnecessary. If several devices share the same family account, note whether the setting is intended to apply to one device or to every signed-in device.
Take a screenshot or export only when it helps prove the current state. Crop it to the relevant settings and remove names, avatars, notifications, and other personal details. A text note is often safer: for example, "app installs require approval; web-content limit enabled; change requested for school research."
Capture the old value and the intended new value
For every setting, record the path to the setting, its previous value, its intended value, and the reason for the change. This is more useful than a general note such as "updated controls." Apple documents that Screen Time settings for a child's device can be managed through Family Sharing, while Google documents that Family Link can manage settings such as apps, screen time, and content restrictions for a supervised account. Those systems have different menus and behaviors, so name the platform and setting rather than assuming one procedure fits every device. See Apple's parental-control guide and Google's Family Link guide.
A compact change row can contain: setting name, old value, new value, device, adult approver, reason, and change time. If a rule has an exception, record the exception separately. That makes it possible to distinguish a broad age-rating rule from a one-app approval.
Preserve proof of the action
After saving, record whether the service confirmed the change, whether it showed an error, and whether synchronization was still pending. A confirmation screen proves that an action was accepted by the interface; it does not prove the rule reached every device. Avoid treating a saved-screen screenshot as the final test.
If the platform provides an activity log or notification, preserve the event identifier or a privacy-trimmed screenshot. Do not copy a child's activity report into the change record unless that report is necessary to validate the specific rule. The evidence file should document administration of the control, not become a surveillance archive.
Test one allowed case and one blocked case
Use a harmless test that matches the rule. For an app-install approval rule, try one age-appropriate free app and confirm that the approval path appears. For a web-content rule, use a known allowed page and a deliberately restricted test category without searching for harmful material. Record the expected result, actual result, device, network state, and test time.
Test on the child's device, because an adult dashboard can show the intended configuration while the endpoint is offline, signed into a different account, or waiting to synchronize. If the result differs from the saved setting, stop and diagnose the account, device, and sync state before making more changes. Multiple rapid edits make the evidence harder to interpret.
Keep a recovery path without storing secrets
Record how an authorized adult can regain administrative access and where the official recovery instructions are stored. Do not put passwords, recovery keys, or parent access codes in the change log. Google explains that a parent access code can be obtained through Family Link or on the web when an authorized parent needs it; the safe evidence is that the recovery method was checked, not a copy of the code itself. See Google's parent access code instructions.
Also record the rollback value: the exact setting to restore if the change blocks a necessary activity or creates an unintended permission. A rollback should restore the last verified state, not a guessed default. After rollback, repeat the same allowed and blocked tests.
Store the evidence with a review date
Keep the record where authorized caregivers can find it but the child or an unrelated user cannot casually browse it. Set a review date for temporary exceptions, device replacements, account changes, or major operating-system updates. Delete screenshots that are no longer needed after the change and rollback window have passed, while retaining a concise text history if accountability still requires it.
A complete record answers six questions: who authorized the change, which account and device were affected, what the old and new values were, why the change was made, how it was tested, and how to recover or reverse it. If any of those answers is missing, the change is not yet well documented.
Sources
- Use Screen Time to manage your child's iPhone or iPad — Apple Support
- Manage your child's Google Account with Family Link — Google Families Help
- Unlock your child's device with a parent access code — Google Families Help