What PCI DSS 1.5.1 asks of dual-connected devices
Picture a laptop that browses the internet, checks email and joins video calls, and also opens a session into the cardholder data environment (CDE). Requirement 1.5.1 asks you to make that device safe to sit on both sides of the boundary. It has three parts: defined configuration settings that stop threats from entering the network through the device, security controls that are actively running, and controls that the user cannot switch off unless management documents and authorizes the change case by case for a limited period. The requirement applies to company-owned and employee-owned devices alike, so a personal laptop that reaches the CDE is in scope even though you do not own it.
The risk here sits on the endpoint, not at the network boundary. A firewall between the internet and the CDE cannot see malware that arrived through a phishing link on a device that later connects to a payment system from inside the office or over VPN. Your network security controls protect the path, but the device is where the infection starts. That is why the standard puts the requirement on the device itself. Your team needs a written configuration standard for each device class, a way to show that the settings are present, and a documented exception process for the rare case when a user must change something.
Three conditions make this hard in practice. Mixed ownership means you may have no management rights over a personal device, so you must decide whether such devices are allowed to reach the CDE at all. Local administrator rights let users disable agents or change settings unless they are removed or tightly controlled. Devices that are offline or roam between networks may miss policy pushes and report nothing for weeks. To prepare, confirm with your assessor which evidence they will accept for each device type, decide which ownership models you will permit, and test whether your tooling can report settings from a laptop that has been off the corporate network for a while. The open-source options described later on this page can help with that check.
Which devices and teams fall under dual-connected rules
Requirement 1.5 applies to any device that can reach both an untrusted network and the CDE, whoever owns it and however often it switches networks. The scoping question is therefore which devices can reach the CDE at all, and the answer should come from your network and data-flow diagrams rather than from asset lists alone.
Company-owned versus employee-owned devices
Requirement 1.5.1 names both company-owned and employee-owned computing devices, so ownership does not remove a device from scope. A laptop bought by the company and a personal laptop with VPN access to the CDE are both in scope if they connect to the internet and to the CDE. Check whether bring-your-own-device policies and mobile device management cover every personal device that has a route into the CDE, and record how each one is configured.
Devices that switch networks
A device that is online at a café and then joins the corporate network through a VPN meets the dual-connection test, even if it only touches the CDE for part of the day. Look for laptops that roam between office, home and public networks, and for devices that hold a persistent tunnel. Confirm with your data-flow diagrams which devices can establish a path to the CDE, and treat any device with that path as in scope for the enforced settings.
Remote and home-office use
Home networks are untrusted networks, and staff working from home often share them with family members and other devices. A remote worker who connects to a CDE jump host from a home router meets the dual-connection test. Ask whether remote access policies require a managed device, and whether your team can verify the settings remotely, because the controls in 1.5.1 must remain active whether the device is in the office or not.
Shared and contractor devices
Shared workstations, kiosks and devices lent to contractors often have access to the CDE without a clear owner. Contractor-owned laptops used on client sites can be the hardest to scope, because your organization may not manage their configuration. Identify every device that a contractor or shared user can log into with CDE access, decide whether the contractor device is allowed at all, and document the answer in your device inventory.
Devices used to administer CDE systems
Administrator laptops are often the most sensitive devices that reach the CDE, because they combine privileged access with general internet use for browsing, email and software updates. Requirement 1.5.1 applies to these devices, and the settings that prevent threats from entering the network matter most here. Confirm which admin workstations are dedicated, which ones also browse the internet, and whether the security settings can be altered by the administrator.
How an assessor tests 1.5.1 on dual-connected devices
This table compares what an assessor does, the evidence they ask for, and the findings they most often raise for Requirement 1.5.1. Read each row as a question the assessor will ask of your environment, and use the right-hand column to check your own readiness before fieldwork begins.
| Assessor activity | Evidence requested | Common findings |
|---|---|---|
| Examine policies and configuration standards | Written policy covering company-owned and employee-owned devices that reach both the internet and the CDE, plus the configuration standard that defines required settings | Policy exists but does not name employee-owned devices or does not define the settings in enforceable terms |
| Examine device configuration settings on a sample of dual-connected devices | Exports of effective settings from a sample of laptops, pulled from the management tool or directly from the device, not from the standard alone | Settings appear in the standard but are not applied to every device in the sample, or drift from the documented baseline |
| Confirm security controls are actively running | Current status reports from endpoint protection, host firewall and monitoring agents, with timestamps close to the assessment date | Agent installed but stopped, out of date, or reporting only at enrollment and not since |
| Confirm users cannot alter the controls | Evidence that settings are enforced by policy or management profile, plus a test showing a standard user cannot disable them | Local administrator rights let users turn off the firewall or agent, and no compensating technical control is recorded |
| Check the exception process | Written exception procedure, approval records signed by management, the defined time limit, and the exception register | Exceptions granted verbally, with no authorization, no end date, or no review once the limit expires |
| Check coverage of the device population | Inventory of dual-connected devices that matches the enrolled fleet in the management platform | Devices that connect to the CDE but are missing from the inventory or never enrolled |
How to implement 1.5.1 step by step
This sequence turns Requirement 1.5.1 from a policy statement into a working set of device settings that users cannot switch off, with evidence an assessor can examine. Each step produces an artifact you can hand to a QSA or internal assessor.
Inventory dual-connected devices from the scoping output
Start from the scoping output for your cardholder data environment and list every company-owned and employee-owned computing device that connects both to untrusted networks, including the internet, and to the CDE. Include laptops, and check whether remote access paths, personal devices used for administration and shared workstations belong on the list. Record owner, user, operating system, network paths and the connection that makes each device dual-connected. Done means the inventory matches the data-flow diagram and a second person has reviewed it. Keep the device inventory as your primary evidence for every later step.
Define the configuration standard for these devices
Write a configuration standard that sets out the required settings for each device type: security agents that must be installed, protections that must stay active, and the settings users must not be able to change. Requirement 1.5.1 expects defined configuration settings that prevent threats from entering the network, so state the threat each setting addresses. Have the security owner approve the standard and tie it to the device types in your inventory. Keep the approved configuration standard with version history as evidence.
Enforce the settings through device management
Deploy the configuration standard through your mobile device or endpoint management tooling so settings are applied centrally and users cannot alter them locally. Confirm with your tooling vendor which settings can be locked and which can only be monitored, because a setting that a user can disable does not meet the requirement. For employee-owned devices, agree on how enforcement works within your acceptable use terms. Keep the deployment policy export and a list of devices that received it as the enforcement record.
Verify that security controls are running and locked
Confirm on each device that required controls are actively running and that users cannot disable or modify them. Osquery can query running processes, loaded kernel modules and open network connections on endpoints, and Fleet policies can ask yes or no questions of devices and show which ones pass or fail. Wazuh Security Configuration Assessment can compare files, registry keys and processes against policies you define. Track failing devices to remediation. Keep the policy results and remediation tickets as evidence that controls run continuously.
Set up the exception and approval process
Define how a user or administrator can receive a temporary change to a locked control. Requirement 1.5.1 allows such changes only when management documents and authorizes them case by case for a limited period, so write a request form, an approver list and a maximum period that your policy sets. Log each exception with its business reason, the approver, the start and end dates and the device affected. Review open exceptions regularly and confirm that each one expires. Keep the exception register and signed approvals as evidence.
Test the result on a sample before the assessment
Before your assessment, select a sample of dual-connected devices across device types, owners and locations and test each against the configuration standard. Examine the policy definitions, the configuration settings on each device and the exception log, which mirrors the examination an assessor will perform. Attempt to change a locked setting as a standard user to confirm it cannot be altered. Record the results, fix gaps and retest. Keep the test script, sample selection and results as the pre-assessment record. Ask any implementation partner to prepare this evidence, but have your internal owner or the independent assessor confirm what the results mean.
Evidence that passes a 1.5.1 assessment
Requirement 1.5.1 is tested by examining policy, configuration standards and the settings actually applied to devices. The six artifacts below connect those layers, so an assessor can trace a written rule to a device setting and to the proof that the setting holds over time.
Written policy and configuration standard
This is the documented rule for dual-connected devices: which company-owned and employee-owned devices fall under 1.5.1, which protective controls each must run, and which settings users may not change. Name the owner of the standard and the approver, and record the review date. Between audits, review it at least when the device fleet, operating systems or the CDE boundary changes, and confirm the approver signs each revision. An assessor will compare the standard against the device exports, so any gap between the two is the first thing to resolve.
Exported device configuration for a sample
Exported settings for a representative sample show the configuration that is actually applied, not what the standard intends. Choose devices across operating systems, departments and ownership types, and export firewall state, endpoint protection status and other settings the standard names. Ask your platform team which query or agent produces each export and keep the query text with the output. Refresh the sample on a schedule you document, and have the security owner sign off on the selection method before the assessor arrives.
Proof that protective controls are running
Assessors look for evidence that required controls are active, not just installed. Keep records that show the process, service or agent is running on each sampled device, such as a status query over running processes or a service state report. Include the time of collection so the evidence reflects a recent state. Gaps between an installed agent and an active one are a common finding, so review devices that report as offline or stopped and document how each was resolved.
List of locked settings
The locked settings register names each configuration that users cannot alter, the enforcement method (such as a management profile or policy push), and the owner responsible for it. Keep it aligned with the configuration standard so that every setting users cannot change appears in both. Review it when operating system versions change, because a setting that locked on one release may not exist on the next. Confirm with your platform team which settings can be enforced on each device type before you list them.
Exception records with authorization and expiry
Where a user needs to change a locked setting, 1.5.1 allows it only when management documents and authorizes the change case by case for a limited period. Each exception record should state the business reason, the specific setting, the approver, the start date and a fixed expiry, plus the compensating check used during the exception. Review open exceptions at a regular interval and confirm each expired one was reverted. Assessors often sample these records, so an exception without an expiry is treated as a control failure.
Periodic check results and sign-off
Periodic checks are the recurring tests that show the settings still hold, such as a scheduled fleet query or a policy pass rate report. Keep the results, the failing devices and the remediation ticket for each failure. Set the check frequency in your own procedure and record who reviews the results and signs them off. A fleet policy tool can report which devices pass or fail each check, which gives you a dated history to show an assessor that drift was caught and corrected.
Open-source tools that produce 1.5.1 evidence
Requirement 1.5.1 asks for evidence that defined settings and running security controls are present on every in-scope laptop and device, not only on a sample. osquery is an open-source agent that exposes operating system data such as running processes, open network connections, browser plugins and file hashes as SQL tables. Its osqueryd daemon can schedule the same queries across a whole fleet, which gives you a repeatable record of device state over time. Fleet, released under the MIT license, builds on osquery by letting you write policies as yes or no questions, such as whether a disk encryption or endpoint protection process is running. Its policies page shows which devices pass or fail each policy, which is the kind of output an assessor can sample against your device list.
- Process and service evidence: Queries against the processes table show whether required security agents are actively running on each device.
- Network state evidence: Open connection queries help show that devices are not carrying unexpected outbound sessions that bypass the controls you define.
- Pass or fail records: Fleet policy results give a per-device view you can export as evidence of consistent checks.
- Scheduled collection: osqueryd runs queries on a schedule, so the record reflects ongoing state rather than a single snapshot.
Confirm the osquery license choice (Apache-2.0 OR GPL-2.0-only) and the Fleet MIT terms with your legal team, and check that your device management approach supports the agent on every operating system you run.
Where the fleet tools answer whether a condition holds, configuration scanners compare device settings with a written standard. Wazuh, licensed under GPL-2.0-only, includes a Security Configuration Assessment module that scans monitored endpoints for misconfigurations. Its checks are written as YAML policies, most of which are based on CIS benchmarks, and you can extend them with your own policies. The checks examine files, directories, registry keys and running processes, and the module recommends remediation for failed items. Its results can show an assessor that the configuration standard you documented for Requirement 1.5.1 is being checked and that deviations are visible.
- Benchmark-based policies: Most shipped policies follow CIS benchmarks, which gives you a documented starting point for your configuration standard.
- Custom policies: Add YAML policies for settings specific to your organization, such as the firewall or user rights your standard requires.
- Registry and file checks: Verify that expected keys and files are present and set correctly on Windows and Linux endpoints.
- Process checks: Confirm that required processes run, matching the requirement that controls remain actively running.
- Remediation output: Failed checks include recommended fixes, which feed your change and exception records.
Confirm which policy files cover your operating systems, review any custom policy against your own written standard, and keep a record of who approved each deviation.
Forensic tools matter when a device behaves unexpectedly or when you need to show what happened during an investigation. Velociraptor, licensed under AGPL-3.0-only, collects forensic artifacts defined in VQL from endpoints. Its hunts collect one or more artifacts across a group of systems at once, and offline machines are scheduled to collect when they reconnect. Each hunt can be analyzed in a notebook that combines the results. This gives your team a documented way to gather the same evidence from many devices, including laptops that are not always online, which is useful when you must confirm that a device's settings or running controls were in place at a given time.
- Group hunts: Collect the same artifacts from every device in a defined group, such as all dual-connected laptops in a business unit.
- Offline queuing: Machines that are off the network collect automatically when they reconnect, which helps with remote workers.
- Hunt notebooks: Each hunt keeps a notebook for analyzing combined results, which supports a documented investigation trail.
- Artifact definitions: Custom VQL artifacts let you collect the specific settings your configuration standard names.
Confirm the AGPL-3.0-only obligations with counsel before deploying, decide where collected data is stored and who may access it, and document each hunt's purpose and approval.
What it costs to meet PCI DSS 1.5.1
This table compares the cost components of meeting Requirement 1.5.1 on dual-connected devices, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No prices or durations are supplied for these components, so use the table to structure your quote request and compare proposals on the same basis.
| Cost component | One-time or recurring | What drives it up | What brings it down |
|---|---|---|---|
| Device management or endpoint tooling licenses | Recurring | Device count, number of operating system platforms, and whether the tool is priced per device | Self-hosted open-source tooling such as osquery, Fleet or Wazuh removes per-device license spend; confirm the platforms each tool covers |
| Engineering time for the configuration standard and enforcement | One-time, with periodic updates | Mixed company and employee ownership, number of platforms, and the number of distinct settings to enforce | A single configuration standard written once and applied across platforms, with enforcement checks defined as queries or policies |
| Evidence upkeep | Recurring | Frequency of device compliance reports, number of devices sampled, and how many systems feed the evidence | Scheduled queries that produce pass or fail results per device, stored in a consistent format for the assessor |
| Exception administration | Recurring | Number of exceptions, since each needs management documentation, authorization and a limited time period | Keep exceptions rare and tied to a defined approval workflow with an expiry date for each one |
| External review or testing | Recurring, at least once per assessment cycle | Scope of the review, whether the configuration standard is tested on sample devices, and the size of the fleet | Written scope that names the devices and platforms in the test, so reviewers do not need to re-derive the population |
| Auditor sampling time | Recurring, each assessment | Number of devices in the population, number of ownership models, and how easily the evidence can be located | A device inventory and evidence schedule that let the assessor select samples without manual reconstruction |
Who does what for dual-connected device controls
Your organization owns Requirement 1.5.1. The standard places the obligation on the entity that stores, processes or transmits cardholder data, so no vendor or assessor can accept that responsibility for you. Your team decides what the device policy says, which users and device types it covers, and who may approve a temporary change to a locked setting. Those decisions need to be written down and traceable, because an assessor will test them against the configuration you actually run.
- Policy ownership: Maintain the written policy that defines which company-owned and employee-owned devices connect to both untrusted networks and the CDE, and what protections apply to them.
- Exception approval: Decide, case by case and for a documented limited period, whether management authorizes a user to alter a protected setting, and record the reason and end date.
- Attestation inputs: Supply the facts your Attestation of Compliance depends on, including the device population, the configuration standard and the scope of the controls.
- Accountability: Assign a named owner who answers assessor questions and signs off on the evidence set.
- Review cadence: Confirm that the policy and device list are reviewed on a schedule you can show.
Before engaging anyone, check that your policy names the device categories in scope and that someone on your staff can explain every exception on record.
An implementation partner such as DeployOpen can prepare the systems and evidence that Requirement 1.5.1 expects. Under a written, fixed scope, the partner can help build the configuration standard, deploy self-hosted tooling inside your environment to enforce and check it, and run internal checks before an assessor arrives. The partner does not decide policy, approve exceptions, or certify that the controls meet the standard. Those remain with your organization and the assessor.
- Configuration standard: Draft the defined settings that prevent threats from entering the network, such as endpoint protection, host firewall and patch status, for your review and approval.
- Enforcement tooling: Deploy self-hosted platforms in your own infrastructure to query devices and flag drift. Candidates include osquery with Fleet policies, and Wazuh Security Configuration Assessment, subject to confirmation against your device estate.
- Evidence preparation: Set up reports and exports that show which devices pass or fail each policy and when they were checked.
- Internal checks: Run a pre-assessment review of the controls to surface gaps your team can fix before the formal assessment.
- Written scope: Agree deliverables, responsibilities and timelines in writing before work starts, and define what the partner will not do.
Ask the partner to name each deliverable and the artifact it produces, so you can match every item to a control in your own evidence set.
The independent assessor tests Requirement 1.5.1 and reports the result. For an entity that completes a Report on Compliance, a Qualified Security Assessor performs this work. Entities that complete a Self-Assessment Questionnaire still need an Attestation of Compliance that reflects accurate answers, and the assessor role depends on the validation route your payment brands require. Under the standard's expected testing, the assessor examines policies, configuration standards and device configuration settings, then decides whether the requirement is met.
- Policy examination: Review the written device policy and confirm it matches the defined scope.
- Configuration review: Inspect the configuration standard and sample device settings to confirm the controls are enabled and cannot be switched off by users.
- Exception testing: Check that each documented exception was authorized and time-limited.
- Reporting: Issue the ROC or the assessment conclusion. DeployOpen does not issue audit reports, attestations or certifications.
- Independence: An assessor that designed or deployed the controls must keep that work separate from its testing, so the partner and assessor roles should stay with different firms where the payment brands or assessor program require it.
Certificates are not recognized as validation under PCI DSS. Ask your assessor which report and attestation form applies to your entity before work begins.
Where organizations fall short on 1.5.1 and how to close it
Requirement 1.5.1 is easy to state and hard to prove across a mixed fleet. The gaps below tend to appear together: an incomplete device list, settings that exist on paper but not on every machine, and exceptions that drift without review. Each card names one gap and a first step that gives your assessor something concrete to examine.
No complete list of dual-connected devices
Many organizations cannot say which laptops and other devices connect both to the internet and to the CDE, so they cannot prove that every one carries the required settings. The list must include company-owned and employee-owned devices. Start by reconciling your asset inventory, VPN and identity provider records, and endpoint agent check-ins against the systems that reach the CDE. Any device that appears in one source but not another is a finding waiting to happen.
Settings documented but not enforced
A configuration standard that describes the required settings does not satisfy 1.5.1 on its own. Assessors look at the actual device configuration, so a firewall or anti-malware setting that exists only in a document will fail. Pick a sample of devices from different groups and compare their live settings with the standard. Scheduled queries that report the state of each device across the fleet turn this comparison into routine evidence.
Local admin rights that switch controls off
When users hold local administrator rights, they can often disable the firewall, endpoint protection or logging that 1.5.1 requires to stay active. The requirement expects these controls to be ones users cannot alter. Review which accounts have local admin rights on dual-connected devices and remove them where the business need is weak. Where admin rights must stay, confirm that the controls still resist change and that any change is detected and reported.
Unmanaged personal devices reaching the CDE
Personal laptops and phones that reach CDE resources through email, remote desktop or browser sessions are often outside the management tooling. These devices sit squarely within 1.5.1 when they connect to both untrusted networks and the CDE. Identify every access path that personal devices use, then decide whether to enroll them, block them, or restrict them to a virtual session where the controls run on a managed host. Document the decision for each path.
Exceptions without authorization or expiry
Temporary exceptions to a locked-down setting are common during troubleshooting, but many are never closed. 1.5.1 allows a control to be altered only when management documents and authorizes the change case by case for a limited period. Keep a register that records the device, the setting changed, the business reason, the approver and the end date. Review open exceptions regularly and confirm each one was reverted when it expired.
No proof that settings held after the assessment
Organizations often verify device settings once, shortly before an assessment, and then have no record of the period in between. An assessor reviewing the year will ask whether controls stayed active throughout. Set up recurring checks that record each device's state over time, and retain the results. Alerts on deviations and a documented response for each one provide evidence that the controls were running continuously rather than only when someone looked.
Questions buyers ask about dual-connected device controls
How much effort does Requirement 1.5.1 take compared with the other Requirement 1 controls?
Requirement 1.5.1 is a single sub-requirement, so its direct technical footprint is narrower than the controls around it, such as the rule sets in 1.2 or the boundary controls in 1.4. The effort comes from the number of devices and how varied they are. A fleet of managed laptops with one standard image is far less work than a mix of company and employee-owned devices, several operating systems and remote users. Most of the effort sits in defining the settings, proving they are enforced on every device, and showing that exceptions are approved and time-limited. Ask your assessor how they plan to sample devices so you can size the evidence work before you start.
Can our team handle Requirement 1.5.1 in-house?
Often yes, if your IT and security staff already manage endpoints and can produce configuration evidence. The work is mostly defining a configuration standard, deploying it through your device management tooling, monitoring compliance, and documenting exceptions. Teams that lack endpoint management, or that have never run a formal exception process, usually need outside help for the setup. Whatever you choose, the organization owns the control. An implementation partner can prepare the tooling and evidence, but the assessor, not the partner, decides whether the control meets the requirement.
What does Requirement 1.5.1 need from IT and security staff?
Each group has a distinct role. IT administrators need to set and enforce the required settings on every in-scope device, including host firewalls, active security software and locked configuration. Security staff need to define the policy, approve exceptions, and review compliance reports. Management must document and authorize any user-alterable setting case by case for a limited period. The assessor will typically examine the policy, the configuration standard and the actual device settings, so both groups should keep records that line up. Ask who owns exception approval and how often device compliance is reviewed before you finalize your roles.
Can BYOD devices fall in scope for Requirement 1.5.1?
Yes, when an employee-owned device connects both to an untrusted network, such as the internet, and to the cardholder data environment. The requirement covers company-owned and employee-owned devices alike, so ownership alone does not remove a device from scope. Organizations usually reduce this exposure by separating access so personal devices cannot reach the CDE directly, or by applying managed controls to devices that do. Your scope decision should be written down and tested, and it should match the network and data-flow diagrams you give your assessor. Confirm the exact boundary with your QSA before you rely on it.
How long does preparation for Requirement 1.5.1 usually take?
No reliable duration is supplied for this requirement, and the answer depends on your environment. Confirm these points in your own estate: how many devices are in scope, whether they run one operating system or several, whether your device management tooling already enforces settings users cannot change, and how many exceptions already exist. Also confirm how quickly your assessor needs evidence and whether your existing policy and configuration standard need rewriting. Ask any implementation partner to base its estimate on a written scope and an inventory of devices, not a generic timeline.
Can an implementation partner issue the Requirement 1.5.1 validation?
No. An implementation partner can help configure endpoints, deploy monitoring and assemble evidence, but it cannot issue a validation or attestation. Compliance is assessed by a Qualified Security Assessor for a Report on Compliance, or documented on a Self-Assessment Questionnaire and its Attestation of Compliance, depending on your validation type. Keep the roles separate: your organization owns the control, the partner prepares systems and evidence, and the assessor reaches the conclusion. If a provider offers to certify the control for you, treat that as a warning sign.
How DeployOpen works on this
DeployOpen helps teams prepare the systems and evidence that a QSA will examine for Requirement 1.5.1, which covers company and employee devices that reach both untrusted networks and the cardholder data environment. The organization owns its controls and its PCI DSS decisions, DeployOpen prepares the configuration baseline, monitoring and documentation, and only the assessor issues the validation.
How we scope
- Confirm which laptops and devices connect to both the internet and the CDE, including company-owned and employee-owned devices.
- Record the device populations, operating systems and access paths in a written scope agreed before work starts.
- Agree in writing which policies, configuration standards and device settings the assessor will examine.
How we build
- Define the enforced device settings that block threats from entering the network and keep them out of end-user control.
- Deploy open-source fleet monitoring, such as osquery with Fleet policies, to check whether each device passes or fails each setting.
- Configure Wazuh configuration assessment policies for endpoints where file, registry or process checks support the baseline.
How we hand over
- Deliver the configuration standard, device policy set and the exception process that records any management-approved, time-limited change.
- Provide pass and fail reports from the monitoring platform so the assessor can see the settings running on each device.
- Document the procedures your team uses to run the controls, along with a list of what the assessor should review.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover, if your team wants it.
- Review device policy results and exceptions with your team on a schedule agreed in the written scope.
- Confirm with your QSA which evidence format they accept before the assessment begins, since requirements for the ROC and the Attestation of Compliance are theirs to apply.
