Before giving an app access to your documents, conversations or accounts, follow the information through the service. Establish what it collects, how it uses that information, who can receive it, and how you can recover access or leave. A useful review ends with a decision and supporting evidence.
At SafeNet 2000 on December 7, 2000, Bill Gates discussed trust, convenience and control, including smart-card authentication and proposed browser privacy mechanisms. Today's cloud services, mobile apps and connected AI tools give those questions a broader setting: information can pass through several accounts, vendors and integrations during one ordinary task.
Ask both the security question and the privacy question
Security: who could gain unauthorized access, change information or interrupt the service, and how would you detect and recover from it? Privacy: what could happen to people because of how information is collected, combined, used, shared and retained—even when the system operates as intended?
NIST's Privacy Framework explanation distinguishes these overlapping risks. An account can be well protected while a service still collects information you would prefer not to provide. Conversely, a restrained collection policy still needs dependable access controls.
Consider a scheduling app. Protecting its account helps prevent an intruder from reading the calendar. Reviewing its permissions and data practices helps you decide whether the app needs every event's description and guest list to find an available time. Those are related but different decisions.
This guide is for individuals, freelancers and small teams reviewing a particular service. Device updates, browser protection and backup configuration are covered in Internet Security Software. Use this review to understand the information entrusted to the service.
Map one real task from collection to deletion
Choose a task and name the information involved. “Cloud storage” is too broad; “share a draft containing customer names with two contractors for one week” gives you something to evaluate. Include information about other people and any contractual or workplace restrictions before uploading it.
Sketch the route in ordinary language: your device → service account → people or integrations with access → exported copies or backups → deletion or retention. Add each place where the information changes hands. Mark uncertainties instead of filling them with assumptions.
On a narrow screen, focus this table and use the arrow keys, or swipe horizontally.
| Stage | Ask | Useful evidence or test |
|---|---|---|
| Collection | Which files, metadata, device details and account permissions are required? | Read the permission screen and compare each request with the task. Try a harmless sample with optional permissions declined. |
| Use | Is information used only to provide the feature, or also for analytics, advertising, model improvement or another purpose? | Record the applicable privacy terms, settings and product plan. Identify which uses you can control. |
| Access and sharing | Can recipients, workspace administrators, support staff, subprocessors or connected apps access it? | Inspect sharing defaults, roles, vendor documentation and integration scopes. Test a link using a separate account with the intended permissions. |
| Retention | How long do originals, logs, recordings and derived outputs remain? | Find the relevant retention setting and any vendor exceptions. Note who can change the setting. |
| Exit | Can you export useful data and remove access and stored copies? | Export a sample, reopen it elsewhere, revoke a test integration and examine the documented deletion process and timing. |
The service privacy and security worksheet gives you a place to record the evidence, date, unresolved question, owner and decision. Keep the worksheet private if it describes real accounts or sensitive workflows; use secure references instead of passwords, tokens or customer data.
Review the controls that make the decision practical
Protect sign-in and recovery together
Enable an appropriate strong authentication method and check how account recovery works. NIST's authentication guidance explains phishing resistance and recovery considerations. Where available, prefer phishing-resistant methods such as properly implemented passkeys or security keys; a typed one-time code has different phishing properties.
Confirm access to the recovery email or other recovery method. Store recovery codes securely, separate from a publicly shared worksheet. Review signed-in devices and sessions. For a team, establish who can restore an administrator's access and remove a departing member. Test recovery planning without disabling your only working sign-in method.
Give integrations only the access the task requires
A connected app may request read access, write access, broad mailbox access or permission to act while you are away. Read the consent screen and the service's documentation for that specific integration. Prefer a narrower scope or a selected-folder connection when it fulfills the job.
Review connections from both ends: the app's settings and the account provider's authorized-app list. Revoking a connection stops the access described by that provider; it may leave previously copied information with the recipient. Record any separate deletion action. For organizational identity, see the single sign-on guide.
Test sharing as a recipient would experience it
Distinguish a named-person invitation, a workspace-only link and a link available to anyone who has it. Check whether the recipient can download, reshare, edit or view older versions. Use harmless content and a separate test account to confirm the boundary. Review existing links after changing permissions.
Encryption claims also need a boundary. Ask who holds the keys and whether the vendor can read the information during processing, support or recovery. Transport encryption, storage encryption and end-to-end encryption describe different arrangements. A badge or broad “encrypted” claim leaves those questions unanswered.
Make leaving a service a tested workflow
Export a sample before committing irreplaceable work. Open it in another suitable application and check attachments, dates, relationships and formatting that matter. Determine whether closing an account also deletes stored content and what the provider retains for backups, logs or other stated reasons.
Your test can demonstrate that an export opens or that a deleted item disappears from your view. Backend deletion timing requires evidence from the provider's applicable documentation or agreement. Write down that distinction. Keep an independent copy when loss of access would prevent you from working.
Apply the same review to AI features and connected assistants
An AI feature can introduce another processing step even inside a service you already use. Before submitting a real document, identify the specific product, account type, plan and feature. Review the terms that actually apply to that combination and the settings controlled by your administrator.
- Inputs and outputs: identify prompts, uploaded files, retrieved documents, recordings, transcripts and generated summaries. An output may repeat sensitive source information.
- Use and retention: check whether material can be used for training or improvement, how long it is retained, and which controls affect which copies. Treat training use and retention as separate questions.
- Connected sources: inspect the accounts, folders, calendars or repositories the feature can read. A convenient broad connection may include much more than the current task requires.
- Actions: distinguish a feature that produces a draft from one that can send messages, change records or share files. Decide who approves consequential actions and how to review their history.
- People and vendors: identify administrative access, human review and additional providers involved, using current documentation. A consumer plan and an organizational agreement may have different terms.
Start with synthetic or otherwise authorized sample information. Verify the result and permissions before expanding the task. If an essential answer remains unclear, use less sensitive data, choose a narrower feature, obtain clarification or select a service whose documented controls fit the need. A useful evaluation can end with “not suitable for this task.”
Worked example: a meeting transcription service
The decision follows the evidence: limited pilot approved; sensitive customer use deferred. A second review can expand the use if the outstanding requirements are met. Record who owns each question and when the team will decide whether to continue.
For a real recording workflow, establish participant notice, permission, organizational policy and any applicable legal requirements for the people and jurisdictions involved. This example supplies a review method; it does not establish permission to record a particular meeting.
Respond to a problem and revisit the decision
If you suspect account compromise, use a known official service address from a trusted, updated device. Follow the provider's recovery procedure; review active sessions, recovery methods and authorized apps, and revoke suspicious access where the service supports it. Changing a password may leave other access paths to review. For a managed account, involve the responsible administrator promptly.
If information was shared too broadly, restrict the link or permissions, record what was exposed and when, and identify who needs to handle the incident. Revocation cannot recall copies already downloaded. Preserve useful evidence while following your organization's response process; notification duties depend on the facts and applicable rules.
Revisit the review when you enable a new feature, change plans, connect another account, add people, receive a meaningful terms change or discover an incident. Also choose a manageable review interval for important services. An owner and a dated evidence record make this more useful than a checklist completed once and forgotten.
NIST's Privacy Framework offers a broader organizational approach. It is voluntary risk-management guidance. A completed worksheet or framework reference does not itself establish legal compliance or certify a vendor.