PE-17 Alternate work site: requirements and evidence

What PE-17 alternate work site requires and why it is hard

PE-17 asks the organization to decide which alternate work sites staff may use, apply defined security controls at those sites, assess whether those controls work, and give employees a way to report incidents to security and privacy personnel. If your system is categorized at the moderate or high baseline and your staff work from home or other non-facility locations, PE-17 applies to you. It is not in the low baseline, and it is not part of the privacy baseline, so a low-impact system does not need to meet it. Confirm the baseline selection in your system security plan before you scope the work.

The risk is straightforward. Laptops, monitors, paper files, removable media and printed records leave the facility and sit in spaces the organization does not control, such as a kitchen table, a shared household or a coffee shop. The control is hard because it reaches past organization-owned space. You cannot install a badge reader in an employee's home, so the organization depends on written approval records, defined minimum controls (for example, full-disk encryption, screen lock, a locked storage option for paper and a rule against shared devices), and staff behavior that you verify through assessment rather than observation. Someone in the organization must own the approval decision, and that decision must be recorded so an assessor can match each remote arrangement to a documented site.

A practical starting point is to list the site types staff actually use, then decide which ones you will permit and under what conditions. Ask endpoint management for device compliance data across remote users, since a tool such as Fleet can show which devices pass or fail yes or no policies, and confirm with HR and facilities how remote work approvals are recorded today. Ask your assessor how they expect to test the effectiveness of controls at alternate sites, because that testing method determines the evidence you need to keep. Finally, confirm the incident contact channel that staff will use from home, and check that it reaches security and privacy personnel during off-hours.

Which alternate work sites and systems fall under PE-17

PE-17 applies only where the system's baseline includes it, and the scope question is decided before any control is written. The cards below cover the decisions that most often change the work: which systems are in scope, who works remotely, which third parties count, and whether remote staff only store data or also access it.

Moderate and high baseline systems

PE-17 is allocated to the moderate and high baselines only, so a system categorized as low impact does not need it. Confirm the impact categorization for each system in the boundary, since a single moderate system can pull a shared platform into scope. Record the baseline selection and any tailoring decisions in the system security plan so an assessor can trace why PE-17 applies or does not apply to each system.

Which roles work remotely

Start with a roster of roles that work from homes or other non-office locations, such as administrators, developers and support staff. Each role that touches the system from an alternate site is a candidate for the defined list of permitted sites. Ask HR and IT for the actual population instead of relying on a general remote work policy, because policy language often lags real practice.

Contractors and third-party staff

Decide whether contractors, outsourced operators and vendor engineers working from their own locations are covered by the organization's definition of alternate work sites. Where they are, the access agreement and the contract should require the same controls and incident contact path that employees use. Confirm this with procurement and legal before the site list is finalized.

Shared and coworking spaces

A coworking space or a shared office is an alternate site with people the organization does not control, so it needs an explicit decision about whether it is permitted. If it is permitted, define the controls that apply there, such as screen privacy, device locking and secure storage, and document who approves its use. If it is not permitted, state that in the work site list and cover it in staff training.

Storage only versus data access

A remote site that only holds backups or encrypted media has a different risk profile from one where staff view, process or administer live data. Document which mode each site uses, because the controls and the assessment depth follow from it. Access from a remote site also brings in AC-17 remote access and AC-18 wireless and mobile access requirements, so check those controls in the same review.

Overlap with AC-17, AC-18 and CP-7

AC-17 covers remote access sessions, AC-18 covers wireless and mobile access, and CP-7 covers alternate processing sites used for contingency. An employee's home can meet the PE-17 definition, the AC-17 definition and, when used for recovery, the CP-7 definition at once. Map each site to these controls so that evidence is reused and no site falls between two owners.

How an assessor tests PE-17 under SP 800-53A

This table maps the four SP 800-53A Rev. 5 determination statements for PE-17 to the examine, interview and test methods an assessor uses, the evidence to prepare, and the findings that appear most often. Read each row as the assessor's question and the organization's answer, and use it to check readiness before fieldwork begins.

Assessment step	Test approach and evidence requested	Common findings
Examine: alternate work site procedures	Assessor reads the procedures addressing alternate work sites for organizational personnel and checks that they name permitted site types, approval steps and who owns the list.	No defined list of permitted sites, or procedures that cover only remote work in general terms.
Examine: required controls for alternate sites	Assessor reviews the written list of security controls required at alternate work sites and compares it with the organization's control baseline for the system.	Controls exist as informal guidance, are not written down, or do not match what the baseline selects.
Interview: personnel who approve site use	Assessor asks the approving officials how site use is authorized, what they check before approving, and how exceptions are recorded. Keep approval records ready for the interview.	Approvers cannot describe the criteria, or approvals are given verbally with no record.
Test: security and privacy processes at alternate sites	Assessor samples a site and asks for evidence that required controls are in place, such as device configuration exports, endpoint policy results or completed self-attestations, and that the organization checks their effectiveness.	No evidence of effectiveness checks, and no test results showing that required controls were confirmed at the site.
Test: staff incident communication path	Assessor asks a sample of staff at alternate sites to show how they would report a security or privacy incident, and checks that the contact reaches a named security or privacy role.	Contact details are outdated, unpublished, or the reporting route is unknown to staff.
Assessor findings	The independent auditor or assessor decides which determination statements are satisfied, partially satisfied or not satisfied. DeployOpen prepares procedures, control lists and test evidence but does not issue findings.	Confirm the assessor's scope and evidence list in writing before fieldwork starts.

How to implement PE-17 step by step

This sequence turns PE-17 from a policy statement into a working program: a defined list of permitted sites, a documented control set, approval records, verified controls, a tested incident reporting path and a scheduled effectiveness assessment.

Define permitted site types and approval path
The organization, through its security and privacy leads with input from HR and facilities, lists the alternate work site types staff may use, such as an employee residence or a contracted co-working space, and states which types are excluded. The same step names who approves each site type and what evidence the requester must submit. The output is a short, approved standard that a reviewer can apply to any request without guessing. It is done when the standard is signed off by the owner of the system and the people who approve use of alternate sites can point to it.
Write the required control set per site type
For each site type, the security team writes the controls that must be in place before work starts. Typical items include full-disk encryption on endpoints, screen privacy for shared spaces, locked storage for devices and paper records, network access only through the organization's approved remote access path, and a rule against printing organizational information at the site. Each control gets a named owner and a way to check it. The output is a control matrix keyed to site type, which later becomes the basis for both the approval form and the assessment.
Set up approval records
Each request to use an alternate site is recorded with the employee, the site type, the approver, the controls the employee attests to, and the approval decision. Approvals are tied to the employee's device and access profile so that removing the approval also removes the ability to connect from that site. The output is a register that an assessor can sample, and that shows who approved which site and when. Confirm whether your identity or ticketing system can hold these records or whether a separate register is needed.
Deploy and verify the technical controls
Engineering turns the technical items in the control matrix into configuration. Device encryption and screen lock policies are enforced through endpoint management, and remote access is limited to the approved path using firewall rules that allow traffic only from the approved remote access source. Compliance checks on endpoints can be run with self-hosted tools such as Fleet, whose policies ask yes or no questions of devices as osquery queries and show which devices pass or fail each one, or Wazuh Security Configuration Assessment, which scans endpoints against YAML policies and recommends remediation. The output is a dated record of passing and failing devices. Verification is complete when each approved device passes its policy or has a documented exception.
Define how staff report incidents
The organization publishes a single, tested route that staff use to report incidents at alternate sites, such as a lost device, a suspected unauthorized viewer, or a stolen printout. The route names the security and privacy contacts, the hours they respond, and what information the employee should provide. The incident response team confirms that reports from alternate sites enter its queue and are triaged like any other incident. The output is a reporting procedure and a test report showing that a sample message reached the right people.
Schedule the effectiveness assessment
The assessor method for PE-17 covers examining the alternate site procedures and the list of required controls, interviewing the people who approve alternate sites, and testing the processes for security and privacy at those sites. The security team schedules this assessment and records who will perform it, which samples of approvals and device checks they will review, and what counts as effective. Assessment results are logged in the plan of action and milestones, with each gap given an owner and a completion target agreed by the organization. The output is a scheduled assessment plan and a POA&M entry for any control that is not yet effective. Confirm the assessment frequency with the authorizing official or your governing policy, since the facts supplied for this page do not set one.

How to verify alternate site controls with open-source tooling

Start with the network path, because a firewall can produce evidence for it directly. For each approved alternate site, confirm that staff traffic reaches internal systems only through a defined VPN or gateway, and that the rule set permits only the sources, destinations, ports and protocols each role needs. In OPNsense, rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses such as an approved remote-access pool. Enable logging on the rules that matter, since each rule match then appears in the live log view for review. Confirm in your environment that logs are retained off the firewall and that someone reviews denied traffic. This evidence covers the path only. It cannot show whether a home router uses a changed default password, so the site controls themselves still need separate checks.

Endpoint configuration checks cover the laptop that leaves the office. Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and accepts custom policies that check files, directories, registry keys and running processes, with remediation recommendations. Translate the settings your organization requires at alternate sites, such as disk encryption, screen lock and host firewall state, into policy checks where the platform supports them, then confirm that the checks run on the devices that travel. Scan results show configuration state at a point in time, so keep the remediation tickets for every failure, because an assessor will ask how gaps were closed. Confirm platform coverage for each check before you rely on it.

Fleet policies answer yes or no questions about each device as osquery queries, and its policies page shows which devices in a fleet pass or fail. Write one policy per required site control, then export the pass and fail history on a schedule to create dated evidence. Add a web application firewall only if staff reach internal web applications from alternate sites. Coraza, which is compatible with ModSecurity SecLang rules and the OWASP Core Rule Set, can sit behind a proxy such as Caddy, HAProxy, Traefik or Nginx. Confirm that the integration is in the request path and that the rule set is loaded. Approval of sites, staff awareness of whom to contact about incidents, and the assessment itself remain process and people evidence.

Evidence that passes a PE-17 assessment

An assessor testing PE-17 asks whether the organization decided which alternate sites are allowed, defined the controls those sites must meet, checked that they work, and gave staff a way to report incidents. The cards below list the records that show each of those decisions, and the routine that keeps each record current between assessments.

Approved alternate site list and criteria

This is the documented list of site types employees may work from, such as home offices or coworking spaces, together with the criteria a site must meet to qualify. Assessors use it to confirm the organization determined the sites it permits, as PE-17 requires. Check that each criteria item is testable, for example a locked room for devices or a private network path, and that the list names an owner. Review it on a fixed schedule and after any change to remote work policy, then keep dated versions so an assessor can see what applied on a given date.

Written control set for each site type

The organization must define the security controls that apply at alternate sites and keep a separate set for each site type where the risk differs. Examples include screen locks, full-disk encryption on laptops, storage of paper records in lockable furniture, and rules against printing sensitive material at home. Assessors examine this list against the criteria above. Keep it under version control so each change has an author, a date and an approver, and map each control to the owner who checks it.

Approval records for individual sites

For each employee who works from an alternate site, keep a record showing who approved the site, when, against which criteria, and which controls were confirmed. Assessors interview the personnel who approve these sites, so the approver must know the criteria and be able to explain them. Record re-approval when an employee moves or the site changes, and remove access when the approval lapses. Ask the organization to confirm whether approvals are held in its HR, IT service management or GRC system, since that choice determines how the export is produced.

Endpoint compliance reports

Reports from endpoint tooling show whether devices used at alternate sites meet the defined controls. Open-source options such as Fleet let teams write yes or no policies as osquery queries, for example whether disk encryption is enabled or a screen lock is set, and show which devices pass or fail each policy. Wazuh Security Configuration Assessment can scan endpoints against YAML policies, mostly based on CIS benchmarks, and recommend remediation. Export these reports on a dated schedule and retain the failing results together with the remediation tickets that closed them.

Firewall and access logs for remote sessions

Logs from the firewall and remote access gateway show that sessions from alternate sites reach only the systems the organization permits. OPNsense rules pass, block or reject traffic by source, destination, port and protocol, and can log each rule match for review in the live log view. Assessors look for evidence that the rules match the approved site criteria and that logs are reviewed. Confirm the retention period with your own logging policy, and export rule sets and log samples at the same dates as the endpoint reports so the two sets can be compared.

Incident reporting channel and test records

PE-17 requires a way for employees to contact security and privacy personnel about incidents at alternate sites. Document the channel, whether a phone line, ticket form or mailbox, the hours it is staffed and who receives the messages. Keep test records showing that staff used the channel and that a message reached the right person and was logged. Test on a scheduled basis and after any change to contact details, and keep the dated test results with any tickets raised during those tests.

Effectiveness assessment reports

PE-17 requires the organization to assess whether the controls at alternate sites work, so an assessor expects a dated report that tests the controls against the written set. The report should record the method used, the sample of sites or devices examined, each finding, and the owner of each corrective action. Assessors read this report alongside the endpoint, firewall and incident channel records to judge whether the organization acts on what it finds. Schedule the assessment at a set interval and after significant changes, and track open findings in a plan of action until they close.

What meeting PE-17 costs in money and effort

This table breaks down the cost components of meeting PE-17 at alternate work sites, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. NIST does not estimate compliance costs, so use the table to shape your questions and request a written quote for each component before committing.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it
Defining permitted sites and site types	Internal policy, HR and security staff, possibly counsel	One-time, then reviewed on a cycle	Number of site types such as home offices, coworking spaces and field sites
Setting the required controls for each site	Security architects and engineers writing the control standard	One-time, then updated as threats change	Number of device types and whether staff handle regulated data off site
Endpoint and network tooling	Software licenses or internal hosting and support staff	Licenses recur; self-hosted tooling carries staff time to run	Number of remote devices and whether existing VPN or endpoint management already covers them
Engineering effort to configure controls	Internal engineers or an implementation partner under a written scope	One-time build, with ongoing changes	Existing remote access setup, identity integration and how many device configurations must be built
Incident contact channel for staff	Security operations staff who receive and triage reports	Setup is one-time; staffing recurs	Expected report volume and hours of coverage
Recurring evidence upkeep	Compliance or security staff collecting site lists, device checks and approvals	Recurring	Frequency of review cycles and the number of remote staff to sample
Effectiveness assessment	Internal assessors or an independent assessor, under a written scope	Recurring at the assessment cycle your program sets	Number of sites and controls, and whether evidence is already centralized
External review and auditor sampling	Independent auditor or assessor fees, set by their own engagement terms	Recurring with each assessment	Sample sizes the assessor selects and how quickly evidence can be produced

Who owns PE-17, who helps, and who assesses it

Your organization owns PE-17 in full. Leadership and the security and privacy functions decide whether alternate work sites are permitted at all, which sites qualify, which controls must be in place at each one, and who may approve exceptions. The control is part of your risk management process, so the accountability cannot be delegated to a vendor or consultant.

Approval decision: Name the role that approves each use of an alternate work site, such as a residence, and record the approval with its scope and date.
Permitted site list: Document the categories of sites staff may use, the minimum controls for each, and the process for adding or removing a site.
Staff accountability: Set rules of behavior and acceptable use for remote work, and enforce them through agreements, training and consequences.
Incident contact: Publish how staff reach security and privacy personnel when something goes wrong at an alternate site, and test that the route works.
Ongoing review: Confirm that the site list and controls are reviewed when the work arrangement, the data involved or the threat picture changes.

Before engaging anyone else, confirm that the policy text, the approval record and the site list exist in a form an assessor can examine.

Common PE-17 gaps and how to close them

Most PE-17 findings come from the same few weaknesses: sites nobody listed, controls nobody checked, and approvals nobody recorded. Each card below names one gap, the action that closes it, and the artifact an assessor would ask to see.

No written list of permitted sites

Without a documented list, the organization cannot show which alternate work sites are allowed, so any home office becomes an unofficial site. Close the gap by defining the permitted site types (for example, a home office at a registered address) and the conditions each must meet. The artifact is a dated alternate work site standard that names those site types and is reviewed on a set cycle. Confirm with your assessor which level of detail they expect for the list.

Controls stated only in policy

A policy that says devices must be encrypted or locked does not show that the controls exist. Assessors look for evidence that the controls are applied on each device used at an alternate site. Use an endpoint configuration check such as Wazuh Security Configuration Assessment or a Fleet policy query to verify disk encryption, screen locking and endpoint agent status on staff laptops, and keep the scan results. The artifact is a dated compliance report per device with failing items tracked to remediation.

Informal approvals

When a manager verbally agrees that an employee may work from home, there is no record that a named official accepted the risk. PE-17 assessors interview the personnel who approve alternate sites, so the approval path must be defined and written down. Create a simple request and approval workflow that names the approver role, records the site, the controls confirmed, and the date. The artifact is a set of approval records for each active alternate site, with reapproval when the site or role changes.

No assessment of control effectiveness

PE-17 requires the organization to assess whether the controls at alternate sites work, not only whether they were promised. Plan periodic checks that combine a sample of attestation reviews with technical tests, such as verifying that a remote session is limited to approved network paths using firewall rule logs. Record what was tested, the result and the corrective action. The artifact is an assessment worksheet that links each tested control to its evidence and the assessor's finding.

Incident contact unknown to staff

Employees at home sites are the first to notice a lost laptop, a suspicious login or a shared printer left unlocked, yet many do not know whom to call. Publish a single incident contact for security and privacy personnel, include it in onboarding and the alternate site standard, and test that staff can reach it outside office hours. The artifact is the published contact page, the acknowledgment records from staff, and a log of test calls or messages with response times.

Home sites handling data with no record

Staff who take work data home create a location the organization may not know about, which makes it hard to reason about scope, retention or breach response. Maintain a register of which employees work from which approved site types, which systems and data classes they use there, and which devices are enrolled. The artifact is that register, reconciled against the device inventory and access logs at each review. Confirm with your privacy team which data classes the register must cover.

PE-17 questions buyers ask before hiring help

Does PE-17 apply to systems in the low baseline?

No. In SP 800-53B, PE-17 is allocated to the moderate and high baselines only, so a system categorized as low impact does not need to meet it. It is also not part of the privacy baseline. Confirm your system's impact categorization and which baseline your authorization or contract uses before scoping work. If your system is moderate or high, PE-17 applies whether or not staff currently work from home, because the requirement is triggered by permitted alternate sites, and the first step is deciding whether any exist.

How long does PE-17 readiness work take?

No timeline for this control has been published, so ask any partner for a written schedule before work starts. The duration depends on how many alternate work site types exist, how many controls already cover remote endpoints, and whether the approval process for remote sites already exists. A workable plan usually breaks into defining permitted sites, documenting required controls, collecting evidence and preparing staff for assessment. Ask for milestones, dependencies on your own approvers, and which items the partner will deliver versus which your team owns.

What drives the cost of PE-17 readiness?

Cost depends on the work needed to meet the requirement, not on the control's name. The main drivers are the number of site types you permit, how much of the required control set already exists for remote endpoints (such as the access control, logging and endpoint configuration that alternate sites rely on), the number of systems in scope, and how much evidence must be collected from staff homes or third-party sites. Recurring costs include reviewing approvals and checking that endpoint policies still pass. Ask every quote to separate one-time design work from ongoing review and tooling.

Can our own staff implement PE-17 without outside help?

Yes, if you have people who understand your physical and remote access controls, your policy process, and the assessment procedures in SP 800-53A. The control requires you to decide which sites are allowed, apply controls there, assess their effectiveness, and give employees a way to report incidents to security and privacy staff. Internal teams often handle the policy and approval steps well and struggle with consistent evidence across many endpoints. Outside help is most useful for building the technical evidence, testing the controls and preparing documents for an independent assessor.

What does a partner need from our organization to start?

A partner needs decisions and access that only your organization can provide. Expect to supply the system boundary and impact categorization, the current list of remote work arrangements, the existing policies covering remote access and physical security, the endpoint management and logging tools in use, and named approvers for alternate sites. You should also name a security and privacy contact that employees can reach about incidents. Agree on who owns each decision in writing, because the organization owns its controls even when an implementation partner prepares systems and evidence.

Can a partner issue the PE-17 assessment?

No. An implementation partner can prepare the controls, documentation and evidence, but only an independent assessor or auditor issues an assessment result or report. Your organization's own assessment or authorization process determines what counts as acceptable. Ask any partner to confirm in writing that it prepares evidence and does not sign assessment conclusions. If you need a formal assessment, confirm with your sponsoring agency, contract owner or authorizing official which assessor qualifications they accept.

How does PE-17 relate to AC-17 and CP-7?

PE-17 sits alongside two related controls in the SP 800-53 catalog. AC-17 covers remote access, so the connections staff make from alternate sites must meet its requirements for authorization, monitoring and protection. CP-7 covers alternate processing sites for contingency operations, which is a different concept from employee work locations, so do not treat one as satisfying the other. In practice, the same endpoint policies, logs and remote access records often serve AC-17 and PE-17 evidence, while CP-7 requires its own planning and testing. Map each control to its own evidence set to avoid gaps.

How DeployOpen scopes and prepares PE-17 evidence

DeployOpen works under a fixed-scope engagement, and the scope is the first decision. Before any work starts, both parties agree in writing which alternate work sites are permitted, which controls apply to each site type, which systems and staff are covered, and what the deliverables and timeline are. For PE-17, the scope should name the remote access path from each permitted site, such as a managed endpoint and a VPN or zero-trust gateway, because that path is what the assessor will test. Your organization still owns the control decisions, including who approves a residence as an alternate work site. DeployOpen does not decide that for you, and it does not publish a price list. A quote follows from the written scope, so the scope document is what drives cost.

Within that scope, DeployOpen configures self-hosted open-source controls inside your own environment and prepares the evidence an independent assessor will examine. Typical work includes restricting remote sessions with firewall rules on OPNsense, defining which endpoints are monitored and how Wazuh Security Configuration Assessment policies are tailored for them, and writing Fleet policies that show whether enrolled laptops meet the required settings. DeployOpen can also assemble the documents the assessor needs for the four determination statements: the procedures for alternate work sites, the control list, the approval records and a record of how staff report incidents to security and privacy personnel. Confirm with your assessor which artifacts they will accept and in what format before configuration starts, because a control that is configured but not documented will not pass.

Ongoing support is optional and is offered as a retainer. Many organizations use one after the initial assessment to review new alternate work site requests, keep endpoint policies current and rerun the evidence collection on a schedule. The retainer scope should state how often reviews happen and who signs off on changes. Remember that DeployOpen does not issue audit reports, attestations or certifications. Only an independent assessor or certification body does that, and DeployOpen's role ends at preparing the systems and evidence for that review.

PE-17 Alternate work site