A mobile permission change can alter access to location, camera, microphone, contacts, photos, or other protected resources. Keep enough evidence to explain the decision and reproduce the result, but do not turn the record into a copy of the protected data itself.
Capture the reason and authority
Record the app, feature, device owner, app-account owner, requested permission, business or personal reason, requester, approver when one is required, and the expected effect. Distinguish a user's operating-system privacy choice from an organization policy. Do not record passwords, unlock codes, recovery codes, or private content from the protected resource.
Android's runtime permission guidance says access should be requested in context and verified whenever protected functionality is used. Apple's privacy and Location Services guidance says people can see which apps requested categories of protected data and grant or revoke access in Privacy and Security settings.
Record the prior state
Before changing anything, capture the date and time, device model, operating-system version, app version, signed-in account type, relevant permission category, current choice, and whether the feature works. Use a written value or a narrowly cropped screenshot that contains no unrelated personal information. If the platform offers limited, one-time, approximate, or while-in-use choices, record the exact option.
Document the change
Note who made the change, the route used in settings, the new value, and any related app or organization-policy change. NIST SP 800-53's configuration change control calls for documenting change decisions, implementing approved changes, retaining records, and reviewing change activity. That structure can inform a small permission record without implying NIST compliance.
Test both outcomes
Open the affected feature and record expected versus observed behavior. Test the normal action, denial or revocation, return from settings, app restart, and device restart when appropriate. Confirm that unrelated features remain usable. If access is not needed, verify that the app handles denial without blocking unrelated work.
Android's permission best practices recommends minimizing requested permissions, testing combinations of granted and revoked access, and handling settings changes or exceptions. Apple's documentation confirms that access can be changed after an app has requested it. Together, these sources support testing the feature after every consequential permission change rather than trusting the settings screen alone.
Close the record safely
Record the test result, remaining limitation, reviewer, next review date, and recovery steps. If the change is temporary, include a clear expiration or revocation date. Store the record where the responsible owner can find it, limit access, and remove obsolete screenshots according to the applicable retention policy. Good evidence proves the decision and result without exposing the contacts, photos, location history, recordings, or other data the permission protects.
Sources
- Request runtime permissions — Android Developers
- About privacy and Location Services in iOS, iPadOS, and watchOS — Apple Support, May 20, 2026
- Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology, Sept. 23, 2020
- App permissions best practices — Google Android Developers