Set a Remote-Work Security Baseline People Can Follow

Start with one bounded workflow

Remote work is not one technical setting. It joins a business workflow to a device category, an identity and access decision, a network context, a physical environment, a communication path, and a continuity plan. A baseline is useful only when those conditions remain visible instead of being compressed into a generic permission to work from anywhere.

NIST SP 800-114 Rev. 1 treats organizational policy, information protection, telework devices, remote access, and home or external networks as related but distinct considerations. NIST’s small-business network guidance places wireless and remote access within a wider network-security context. CISA’s Federal Mobile Workplace Security guide shows that a formal federal program may define roles, responsibilities, participation conditions, and training.

Those sources support a layered baseline and visible organizational conditions. They do not prescribe the nine concepts, eight stages, seven states, 18 fields, evidence threshold, exception rule, completion criteria, or review cadence below. Those are PlainFort editorial judgment—not NIST or CISA requirements, certification, compliance, legal or HR advice, a security guarantee, or a universal remote-work model. The CISA material is federal context, not a mandate for a small team.

Use this guide for one bounded workflow or worker category at a time. A completed record does not prove that a device, network, location, account, person, or workflow is secure. It does not authorize monitoring, surveillance, location collection, or a live technical change.

Keep nine baseline concepts separate

1. Business workflow and data boundary — the bounded work and information category in scope.
2. Internal ownership and authority — accountable owner, responsible coordinator, genuine backup, decision authority, and escalation authority.
3. Device category and admission state — the existing company-device or personal-device decision, without repeating it.
4. Identity and access prerequisites — the existing MFA and privilege decisions, without selecting or configuring them here.
5. Network context and traffic-protection decision — the category-level setting and existing VPN-fit decision, without validating a network.
6. Physical environment, privacy, and shared-space boundary — visibility, conversation, storage, and interruption conditions without collecting a precise location.
7. Communication and reporting path — approved routes for routine support, suspicious messages, loss or theft, and urgent escalation.
8. Support, continuity, backup, and loss handoff — service availability, safe fallback, unavailable-owner coverage, and the dedicated loss or theft path.
9. Evidence, exception, residual risk, escalation, and review — what is documented, reported, unknown, blocked, deferred, excepted, or due for review.

Do not collapse these concepts into one remote work allowed, VPN enabled, approved device, compliant, or secure checkbox. A good state in one concept cannot silently compensate for an Unknown, Blocked, Deferred, or Exception state elsewhere.

Keep network and physical context categorical

Use categories such as Managed work location, Home or private location, Shared or public location, and Unknown — qualified review required. Do not record a network name, address, router, provider, endpoint, topology, configuration, traffic observation, or test result.

Physical context can expose work through visible screens, overheard conversations, unattended devices, shared surfaces, interruptions, or unavailable support. Record the category and the necessary boundary—not a home address, precise or live location, household detail, itinerary, accommodation, travel date, border-crossing detail, employee movement history, or surveillance output.

Business need cannot override privacy, employment, legal, accessibility, or safety constraints. An unknown or high-impact constraint requires qualified review rather than covert monitoring or a universal prohibition.

Use eight stages to set the baseline

The sequence, states, fields, evidence threshold, exception rule, completion criteria, and review cadence are PlainFort editorial judgment. A smaller record may use shorter answers, but it must not hide ownership, a dedicated-guide dependency, evidence quality, an exception, or a stop condition.

1. Bound the workflow and decision authority

Describe the business workflow and information category without copying content. State what is permitted, what is outside scope, and which change would reopen the record. Assign an internally accountable owner, a responsible coordinator, a genuine backup, and the authority that can accept an exception or require escalation.

A title alone does not prove competence, capacity, independence, or authority. If the named owner cannot obtain evidence or stop unsafe work, record the gap instead of treating the assignment as complete.

2. Consume the device and admission decisions

Reference the approved company-laptop baseline or personal-device admission record. Do not repeat its checks and do not inspect, enroll, configure, approve, lock, wipe, or remove a device here.

An Approved article is editorial guidance, not approval of a particular device. A reported device state is not inspected evidence. If ownership, support, update status, separation, privacy, or exit conditions remain unclear, use Unknown, Blocked, or Dedicated-guide decision required.

3. Consume identity, privilege, and VPN-fit decisions

Reference the existing MFA-method and administrative-account decisions. Record the access category and whether privileged work is in scope, but do not select an authenticator, perform enrollment or recovery, create an account, change privilege, or design elevation.

DN-19 owns the bounded VPN-fit decision. DN-20 records that outcome without repeating the VPN decision or treating a VPN as proof of safe remote work. If the traffic-protection need is unresolved, keep it visible rather than substituting a product label.

4. Classify network and physical-environment categories

Record only the network-context and physical-environment categories needed for the workflow. State which general conditions would stop the work—for example, inadequate visual privacy, an unknown connection context, or no safe way to protect a sensitive conversation—without collecting a place, person, household, device, or network identifier.

Do not infer that a home location is safe or that a public location is always unsafe. The relevant question is whether the recorded conditions and constraints are supported for the bounded workflow.

5. Define data-handling and communication conditions

State which workflow and information categories may be handled and which must wait for a different approved environment or qualified decision. Use inert references to evidence held in an approved system; do not copy business content, messages, records, screenshots, logs, or configuration.

Name the approved route for routine support and suspicious-message reporting. EP-13 owns reporting, triage, feedback, and incident handoff. DN-20 does not ask someone to forward suspicious content or determine whether a message is safe or malicious.

6. Plan continuity and dedicated handoffs

Record what happens when the primary owner, device category, service, access path, or work environment is unavailable. A safe fallback may be another already-approved workflow category or a stop-work condition. It is not permission to bypass an account, device, network, privacy, or authorization control.

DN-18 owns preparation for loss or theft and its higher-risk action boundaries. DN-20 records only the approved loss or theft handoff; it does not locate, lock, wipe, recover, inspect, or act on a device. Suspected compromise or another incident also leaves this guide and goes to qualified response.

7. Record evidence, exceptions, and residual risk

Use these states:

• Baseline condition documented — evidence referenced
• Reported — evidence not inspected
• Unknown — follow up through approved route
• Blocked — qualified help required
• Deferred — owner and review trigger required
• Exception — owner, boundary, expiry, and review required
• Dedicated-guide decision required

These are workflow positions, not a security score, risk rating, compliance state, authorization of a person or location, or proof of effectiveness. Never choose a convenient state merely to make the record look complete.

Every exception needs an owner, reason, bounded scope, compensating condition when justified, expiry or exit condition, residual risk, and review trigger. An exception without ownership, a limit, or a review point is an escalation—not an accepted completion state.

8. Close only with evidence and a review trigger

Closure requires a bounded workflow, internal ownership and authority, visible device/access/network dependencies, truthful evidence states, a safe communication and continuity path, recorded exceptions, residual risk, and a next review trigger. Reported is different from Evidence inspected; neither proves effectiveness.

Do not issue a combined approved for remote work result that hides a gap. Reopen the record when the workflow, information category, device/admission decision, identity or privilege decision, network context, VPN-fit decision, physical environment, provider or support dependency, continuity path, exception, evidence, or official guidance changes.

Stop before live or high-impact work

Stop and seek qualified help when:

• device ownership, admission, support, update, separation, or exit state is unknown;
• privileged or sensitive work lacks a current access decision or appropriate authority;
• network context or traffic-protection need is unclear;
• the physical environment creates an unresolved privacy, safety, confidentiality, accessibility, employment, or legal constraint;
• an owner, genuine backup, escalation authority, reporting route, or safe continuity path is absent;
• loss, theft, suspected compromise, a suspicious message, or another incident changes the task;
• travel, jurisdiction, contract, records, privacy, or regulated-data questions require qualified review; or
• the next step would require inspection, monitoring, surveillance, precise-location collection, telemetry, lookup, scan, traffic capture, connection, configuration, enrollment, account access, credential handling, recovery, wipe, or another live action.

These are escalation triggers only. This guide does not diagnose, configure, monitor, contain, recover, wipe, make a legal or HR determination, assess travel risk, or respond to an incident.

Keep dedicated guides separate

DN-16 owns the company-managed laptop baseline. DN-20 consumes its recorded state without repeating or performing the device checks.

DN-17 owns personal-device admission, privacy, separation, support, and exit. DN-20 cannot admit a personal device.

DN-19 owns the bounded VPN-fit decision. DN-20 records its outcome without choosing a provider, protocol, or configuration.

DN-18 owns preparation for device loss or theft. DN-20 provides a handoff, not loss or theft instructions.

AA-07 owns MFA-method choice, fallback, device dependency, and recovery trade-offs. DN-20 records the dependency without choosing a method.

AA-08 owns everyday and administrator account separation, elevation, and privilege exceptions. DN-20 does not design administrative identities.

EP-13 owns suspicious-message reporting, triage, feedback, and incident handoff. DN-20 records the reporting route without copying message content.

Use an 18-field vertical remote-work baseline record

Use one vertical record per bounded workflow or worker category. Do not turn it into a wide table, scorecard, heat map, employee-monitoring form, location log, itinerary, network inventory, configuration worksheet, architecture approval, legal or HR assessment, or compliance checklist.

1. Bounded remote-work scenario and workflow or data boundary: category-level work, permitted information class, and explicit exclusions.
2. Internally accountable owner: organizational role; naming it does not prove competence, capacity, independence, or authority.
3. Responsible coordinator, genuine backup, and authority or escalation path: distinct roles plus any coverage gap.
4. Worker and device category: generic category only, without identity or device detail.
5. Device or admission dependency and evidence state: DN-16 or DN-17 result plus Documented, Reported, Unknown, or Blocked.
6. Identity, MFA, privilege, and access dependency: existing AA-07 or AA-08 decision and unresolved handoff.
7. Network-context category: managed, home/private, shared/public, or unknown; no network identifier.
8. Traffic-protection or VPN-fit decision: existing DN-19 outcome, assumptions, and unaddressed gaps.
9. Data-handling and storage boundary: what is permitted, prohibited, deferred, or routed elsewhere.
10. Physical privacy and shared-space boundary: general visibility, conversation, storage, and interruption conditions.
11. Approved communication, support, and suspicious-message reporting path: inert route reference without copied contact or content.
12. Update, support, and provider dependency: current dependency, owner, evidence state, and support limitation.
13. Backup, continuity, and safe-fallback condition: approved alternative or stop-work condition, plus genuine backup coverage.
14. Travel or public-location boundary: category-level constraints and qualified-review trigger; no itinerary or precise location.
15. Exception, owner, scope, expiry, and review condition: visible deviation and its bounded lifecycle.
16. Non-sensitive evidence references, unknowns, and evidence quality: approved evidence location and Documented, Reported, Unknown, or Blocked state.
17. Residual risk, stop result, and qualified escalation: what remains open, why work stops, and the receiving role.
18. Completion evidence and next review trigger: what was inspected, reviewer role, incomplete items, and the change that reopens the record.

Fictional example — do not copy as a completed device or network record

1. Bounded remote-work scenario and workflow or data boundary: Example Co. is documenting one routine collaboration workflow; sensitive administrative work is excluded.
2. Internally accountable owner: Operations lead.
3. Responsible coordinator, genuine backup, and authority or escalation path: Operations coordinator; backup is Unknown — follow up through approved route; the owner can stop the workflow.
4. Worker and device category: Approved role category using an organization-managed device category; no identity or device detail is recorded.
5. Device or admission dependency and evidence state: DN-16 outcome is Baseline condition documented — evidence referenced at an approved evidence location.
6. Identity, MFA, privilege, and access dependency: AA-07 decision is Reported — evidence not inspected; administrative access is outside this workflow.
7. Network-context category: Home or private location; the connection itself has not been validated.
8. Traffic-protection or VPN-fit decision: DN-19 result says Not required for this bounded use case — alternative and evidence documented; this does not remove other controls.
9. Data-handling and storage boundary: Routine collaboration content only; restricted workflow categories require a different approved decision.
10. Physical privacy and shared-space boundary: The worker must stop if screen or conversation privacy cannot be maintained; no household or location detail is recorded.
11. Approved communication, support, and suspicious-message reporting path: Approved support route — contact and account details not copied; EP-13 owns suspicious-message reporting.
12. Update, support, and provider dependency: Support state is documented; current provider evidence is referenced but not copied.
13. Backup, continuity, and safe-fallback condition: Stop work and use the approved support route if the primary path is unavailable; genuine backup coverage remains unknown.
14. Travel or public-location boundary: Dedicated-guide or qualified decision required before this workflow moves into a shared, public, or travel category.
15. Exception, owner, scope, expiry, and review condition: No exception is accepted; the missing backup has an owner and review trigger.
16. Non-sensitive evidence references, unknowns, and evidence quality: Remote-work baseline evidence — details held in approved system; device state is documented, access and backup states are reported or unknown.
17. Residual risk, stop result, and qualified escalation: Continuity and evidence gaps remain; the operations lead must escalate before expanding the workflow.
18. Completion evidence and next review trigger: Record remains Blocked — qualified help required until genuine backup and access evidence are inspected; reopen on any workflow, device, access, network-context, support, or guidance change.

The unresolved backup and evidence gaps prevent this fictional record from becoming a false completion.

Where this guide stops

This guide creates a baseline record; it does not validate a device, account, network, physical environment, traffic path, provider, location, travel condition, monitoring arrangement, or protection outcome. Do not use it to inspect, monitor, surveil, locate, scan, capture traffic, connect, enroll, configure, recover, wipe, change access, choose a product, or respond to an incident.

Seek qualified IT, network, security, privacy, legal, HR, accessibility, travel-risk, records, contractual, or incident-response help when authority or architecture is unclear, sensitive or privileged work is in scope, privacy or employment constraints are material, a safe fallback is absent, loss or suspected compromise changes the task, or live work could cause exposure, interruption, lockout, evidence loss, or data loss.