A Digital Security Baseline for Freelancers and Small Teams

A freelancer can lose access to work without experiencing a sophisticated cyberattack. A phone replacement can remove an authenticator app, a client folder can inherit the wrong sharing setting, or an old contractor can retain access because nobody recorded which accounts they used.

This guide creates a small, reviewable security baseline for people who do not have an IT department. It is not a promise that the controls will prevent every incident. The goal is to identify the few accounts, files, devices, and recovery dependencies that would cause the most disruption if they failed.

Method note: This is a documentation-based planning guide, checked August 12, 2026. The worksheet and priority method are original to Safer Digital Desk. The control themes are aligned with the NIST Cybersecurity Framework 2.0 Small Business Quick-Start Guides and CISA's Secure Our World guidance.

A baseline works as a review loop: inventory the system, apply proportionate controls, verify them, and revisit them after change.

Start With the Work That Must Continue

Do not begin by listing every app you have ever installed. Start with three or four activities that must continue for the business to function. For a freelance designer, that might be receiving client email, accessing current project files, sending invoices, and joining scheduled calls. A small consulting team might also need its shared calendar, password manager, domain registrar, and administrator account.

For each activity, ask:

• Which account opens the door?
• Where is the working data stored?
• Which device or person is required?
• What recovery method would work if the usual device disappeared?
• Who could verify a payment or access change through a separate channel?

This produces a dependency map rather than an app inventory. It exposes situations such as a domain registrar and recovery email depending on each other, or every backup code being stored inside the account those codes are meant to recover.

The Baseline Worksheet

Copy this table into a private document or spreadsheet. Do not enter passwords, recovery codes, private keys, full payment details, or confidential client data. Record where a protected item is kept, not the secret itself.

Work function	Critical account or asset	Owner/admin	Sign-in protection	Recovery path	Backup or export	Next check
Client communication	Business email	Named account owner	Passkey, security key, or MFA method	Separate recovery method recorded	Provider-specific retention/export plan	Date and responsible person
Current project work	Shared file location	Workspace administrator	Protected admin and member accounts	Second administrator or documented process	Tested copy or restore method	Date and responsible person
Domain and website	Registrar and DNS account	Named account owner	MFA plus registrar lock where available	Recovery email not dependent on the domain	DNS/configuration record	Date and responsible person

Add rows for invoicing, scheduling, source code, contracts, social accounts, and any regulated or contractually protected data that actually exists in your workflow. A blank field is a finding, not a reason to guess.

Worked Example: A Fictional Two-Person Design Studio

The following example uses a fictional business called Harborline Design. It is not a client, survey result, or account we assessed. The details were created to demonstrate how the worksheet exposes dependencies.

Work function	Critical dependency	What the worksheet reveals	First bounded action
Client email	Custom-domain mailbox	The mailbox recovery address uses the same custom domain	Add and verify an independent recovery route before removing the old one
Domain and DNS	Registrar owner account	Only one person controls MFA and renewal notices	Document ownership, billing, recovery, and an authorized continuity process
Current client files	Shared cloud folder	A public link created for a review has no recorded end date	Check the link with fictional test content, then remove or restrict it if no longer needed
Daily sign-in	One partner's phone	The password manager and authenticator are both available only on that device	Review the products' recovery and transfer instructions and establish an independent fallback
Project archive	Synced drive folder	No one has restored a file to confirm that history and permissions survive	Restore a fictional test folder to a separate location and record the result

Finding 1: a circular recovery path

The business email depends on the custom domain, but its recovery address also uses that domain. If DNS, billing, or domain control fails, the recovery message may be unreachable. The first action is not to replace every account. It is to establish and verify an independent route without removing the known working method prematurely.

Finding 2: one device holds several roles

The phone is simultaneously a signed-in device, authenticator, password-manager access point, and recovery number. Listing “MFA enabled” would hide that concentration. The worksheet turns it into a concrete question: what remains available after that phone is lost?

Finding 3: synchronization was mistaken for recovery

The studio can see files on two computers, but it has not confirmed whether an accidental deletion, overwritten document, or permission problem can be reversed. A small restore using fictional files is a safer next step than assuming synchronization is a backup.

How the studio chooses the first three actions

Harborline ranks an action higher when one failure can block several work functions, when no independent recovery method exists, or when an outsider may retain access. Its first three actions are therefore: verify independent recovery for email and the registrar, review the client-sharing link, and perform a separate-location restore test. Lower-impact app preferences wait.

This example is intentionally incomplete. A real business may have contractual retention, privacy, insurance, or regulatory requirements that change the order and require qualified review.

Priority 1: Protect the Accounts That Can Reset Other Accounts

Your primary email, password manager, domain registrar, cloud workspace administrator, and device-platform account often control recovery for other services. Protecting a low-impact app while leaving one of these accounts dependent on a reused password does not create a useful baseline.

CISA recommends multi-factor authentication and notes that stronger, phishing-resistant options should be used when available. Review CISA's direct MFA guidance. The right method still depends on provider support, device access, recovery, and the people who need to sign in.

For each high-impact account:

1. Confirm the account owner and at least one current recovery method.
2. Use a unique credential stored in a reputable password manager if a password remains part of sign-in. CISA's password guidance explains the value of long, random, unique passwords and password managers.
3. Enable the strongest practical MFA or passkey option the provider supports.
4. Record where recovery instructions and backup methods are kept without copying secrets into the worksheet.
5. Remove obsolete phone numbers, devices, app passwords, and recovery addresses only after verifying the replacement works.

Failure case: recovery depends on the locked account

If the only recovery email uses the same custom domain as the unavailable mailbox, a DNS or billing problem can block both the account and its recovery path. Likewise, backup codes stored only in that mailbox are unavailable when the mailbox is locked. The worksheet should show an independent recovery path.

Priority 2: Reduce File-Sharing Exposure

List where active client and business files live. Then distinguish named-person access from link-based access. A link that worked for a short project may remain active after the engagement ends, and a shared parent folder may expose more than the file a client needs.

For each important location:

• Identify its owner and administrator.
• List external people or domains with access.
• Record whether access is view, comment, edit, download, or administrator level.
• Check whether a link works without signing in.
• Set a review date tied to the end of the project.
• Separate clients or projects when inherited access would reveal unrelated files.

Do not open real client material merely to complete an audit. Start with provider access reports or a test folder, then inspect sensitive locations under the organization's own authorization and handling rules.

Priority 3: Know Which Devices Hold Work Access

A device list should include laptops, phones, tablets, security keys, and shared office equipment that can access business accounts or hold synchronized files. Record the owner, supported operating system, encryption status where verifiable, update status, screen lock, and what remote-loss controls are available.

CISA recommends installing software updates and enabling automatic updates where appropriate; see its direct software update guidance. Automatic updating does not remove the need to confirm that an unsupported operating system or abandoned application is still receiving security fixes.

Failure case: the second factor is on the lost device

A phone can hold the password manager, authenticator, email session, and recovery number at once. Before treating MFA as complete, document how a replacement device would be enrolled and which independent method is available. Do not test this by erasing the only working device.

Priority 4: Make a Backup Useful by Planning the Restore

“Backed up” is incomplete unless you know what was copied, when it was copied, who can restore it, and where the restoration can safely occur. File synchronization can reproduce a deletion or unwanted change; version history and separate backups serve different purposes.

For each critical data set, record:

• What must be recoverable
• The acceptable amount of lost work
• How long the business can wait for restoration
• Whether the backup uses a separate account, device, or location
• Who can initiate a restore
• The date a non-sensitive test file was last restored

A first test can use a newly created folder containing fictional documents. Restore it to a separate location, open each file, and record what happened. Do not overwrite the working copy during an initial test.

Priority 5: Prepare for Phishing and Payment Changes

Technical controls cannot decide whether an unexpected payment request is legitimate. Create a verification rule before an urgent message arrives: changes to bank details, passwords, administrator access, or recovery information must be confirmed through a trusted channel that did not come from the request itself.

CISA's phishing guidance recommends recognizing, resisting, and reporting suspicious messages. For a tiny team, “reporting” may mean forwarding the message to the designated owner and contacting the vendor through a known phone number or previously verified portal.

Assign Owners and Review Triggers

A baseline goes stale when every row says “team.” Assign a named owner or role and a next check. Calendar intervals help, but event-based reviews are often more important.

Review the affected rows after:

• A contractor or employee joins or leaves
• A phone, laptop, authentication method, or administrator changes
• A new client requires different handling
• A provider changes its recovery or sharing controls
• A suspicious sign-in, lost device, accidental share, or restore failure occurs

When This Baseline Is Not Enough

This worksheet is not a compliance assessment, penetration test, incident-response plan, or substitute for professional review. Seek qualified help when the business handles regulated information, has contractual security obligations, faces an active compromise, must preserve evidence, or cannot determine the impact of a configuration change.

When the worksheet exposes a weak area, continue with the task-specific control: choose an authentication method with a workable recovery path, match a client-file transfer method to the data, turn the asset map into a laptop backup plan, or define an independent check for payment-change email.

A Useful First Session

Limit the first session to the five accounts or assets that can stop the most work. Complete the worksheet fields you can verify, mark unknowns, and select one recovery or access test that can be performed safely with fictional data. The output should be a short list of owned actions—not a claim that the business is now “secure.”