Safeguard 10.6 Central anti-malware management explained

What central anti-malware management requires and why assessors care

If your IG2 team has anti-malware running on most machines but cannot show, from one place, which policies apply, which endpoints report, and what has been detected, Safeguard 10.6 is the gap you are being asked to close. The safeguard asks the enterprise to manage its anti-malware software centrally, so that policy, health status and detections are visible across the whole fleet rather than inspected machine by machine. It sits on top of the per-asset deployment in Safeguard 10.1, which asks only that anti-malware be installed and kept maintained on every enterprise asset. Installation proves coverage on a given day. Central management proves that someone can see and change that coverage across the fleet at any time. CIS assigns 10.6 to the Devices asset class and the Protect security function, and places it in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. Confirm your own IG against the CIS Implementation Groups pages before you scope the work.

Assessors care because the CIS Controls Navigator maps 10.6 to NIST SP 800-53 Rev. 5 control SI-3, to ISO/IEC 27001:2022 Annex A control 8.7 and to SOC 2 criterion CC6.8. In practice, that means the same evidence may be asked for by a CIS assessor, an ISO auditor and a SOC 2 examiner, so a central console that produces one clean export serves several engagements. The Assessment Specification measures 10.6 with a Coverage metric, the share of anti-malware that is centrally managed, and it lists 1.1, 2.1 and 10.1 as prerequisites. That means the console can only be as useful as the asset inventory and software inventory behind it. Ask which asset records and agent registrations feed the console, and who reconciles them.

Three problems make this harder than it looks. The first is consoles that are not inventoried: a management server or cloud tenant that exists in one team's runbook but not in the asset register, so nobody reviews its policies. The second is agents that report to nowhere: endpoints where the anti-malware runs but its check-in has failed, lapsed, or points at a retired server, which looks covered on a spreadsheet and is invisible in the console. The third is unmanaged exceptions: local overrides, excluded paths and standalone installs that someone granted for a legitimate reason and never recorded. Before you commit to a remediation plan, pull one month of console data and compare the agent count with your asset inventory. The difference is the scope of your 10.6 gap.

Which endpoints, consoles and teams fall under Safeguard 10.6

Safeguard 10.6 applies only once an enterprise has anti-malware on its assets and needs to see it from one place. The decisions below determine how much of the fleet, which consoles and which teams the central management layer must cover, and they depend on the asset and software inventories already being in place.

Enterprise assets that carry anti-malware

Start with the set of devices that 10.1 says must run anti-malware, then confirm each one appears in the central console. Coverage is measured as the share of anti-malware centrally managed, so a laptop that runs a local copy of the product but reports to nobody counts as a gap. Ask whether mobile devices, network-attached devices and any unmanaged endpoints are inside the agreed boundary, and record the exclusions with a reason.

Servers, virtual machines and cloud workloads

Servers, virtual machines and cloud instances are assets like any other in the inventory, so they belong in the Coverage calculation unless the enterprise documents a justified exclusion. Short-lived autoscaled instances are the common failure point, because they can start and stop between console sync cycles. Confirm that images or deployment templates install the agent and register it with the console at build time.

Standalone and vendor-hosted consoles

Some products run a local console on each site, while others are managed by the vendor. A standalone console still counts as central management if one team can see policy and detections across all sites, but several disconnected consoles usually fail that test. For a vendor-hosted console, the enterprise still owns the policy decisions and should confirm where detection data is stored and who can export it.

Inventory prerequisites from Controls 1 and 2

The Coverage metric is only as accurate as the asset list it divides by. Safeguard 1.1 provides the detailed enterprise asset inventory and Safeguard 2.1 provides the software inventory, and the assessment specification names both as prerequisites for measuring 10.6. If the console reports 90 percent of a list that is missing a third of the fleet, the reported coverage is wrong, so reconcile the console against the inventory before the first measurement.

Policy ownership versus alert triage

Decide who writes and approves the anti-malware policy, usually the security function, and who acts on detections, usually a security operations or endpoint team. Write the handoff down, including who can change exclusions, who can isolate a host and who receives alerts outside working hours. Without that split, policy drifts across consoles and alerts sit unassigned.

Scope for IG1-only enterprises

Safeguard 10.6 is an IG2 Safeguard, so an enterprise that qualifies only for IG1 is not required to meet it. Such an enterprise still needs anti-malware on every asset under 10.1, and a central console can still help it, but the console is not what the Safeguard tests. Confirm the Implementation Group decision before scoping this work, since it changes what an assessor will measure.

How an assessor tests central anti-malware management

This table sets out the test approach the CIS Controls Assessment Specification implies for Safeguard 10.6, step by step, with the evidence an assessor typically requests and the findings that come up most often. The assessor measures the Coverage metric, but the enterprise decides how to produce the numbers, so read each row as a question to answer with your own console data before the assessor arrives.

What is tested	Evidence requested	Common finding
Prerequisites 1.1, 2.1 and 10.1 in place	Current enterprise asset inventory, software inventory and anti-malware deployment records that the assessor can reconcile with the console	Console shows agents on hosts missing from the asset inventory, so the denominator for coverage is unreliable
Coverage metric: share of anti-malware centrally managed	Your calculation method written down, the numerator from console exports and the denominator from the asset inventory, with the date of each extract	Coverage calculated from console counts alone, without a reconciled asset list, so unmanaged devices never enter the figure
Sample of assets checked against console records	Selected endpoints and servers shown in the console with agent version, policy name and last check-in time	Sampled machines appear in the console, but the agent reports a stale check-in or a local-only configuration
Policy assignment across the fleet	Central policy definitions, assignment rules by group or asset class and change history for those policies	Devices fall into a default policy nobody reviewed, or servers and virtual machines inherit a workstation policy
Alert and detection handling	Alert queue, triage records, escalation rules and examples of closed detections with the action taken	Detections are visible in the console but no owner or closure record exists, so the assessor cannot see that management acts on them
Unmanaged exceptions	Documented exception register with reason, approver, compensating control and review date for each unmanaged asset	Exceptions exist informally in email or tickets, with no compensating control and no expiry date

Evidence that shows central anti-malware management is working

Safeguard 10.6 is only as credible as the records behind it. The cards below cover the artifacts an assessor will ask for, and each one answers a different question: is coverage complete, is policy applied, are exceptions approved, are detections handled, and is the console itself controlled. Keep each artifact dated and exportable so it can be shown without rebuilding it at audit time.

Timestamped coverage report

A console-generated report showing which enterprise assets report to the central console, which have anti-malware installed, and when the data was pulled. This is the raw input for the Coverage metric in the CIS assessment specification, which measures the share of anti-malware centrally managed. Check that the asset count in the report matches the asset inventory from Safeguard 1.1, because a coverage figure built on a smaller population than the real fleet will not survive testing. Schedule the export and store each copy with its date, so the trend is visible between audits.

Policy set and device group assignments

The central policy definitions, such as scan schedules, real-time protection settings, exclusion rules and update channels, together with a record of which device groups each policy is assigned to. Assessors look for a policy that applies to every managed asset class, not a default policy that nobody reviewed. Export the policy configuration with a version or change identifier, and keep a mapping from each device group to the assets it contains. A policy that exists on paper but is assigned to an empty group provides no protection.

Unmanaged and excluded asset register

A list of assets that are not reporting to the console, or that are excluded from policy, with the approval for each entry. Exclusions are normal for some systems, such as appliances or isolated lab hosts, but each one needs a named owner, a reason and an approver. Review this list against the Safeguard 1.1 inventory and against the unauthorized asset process. Ask whether any exclusion covers a whole network segment, since a broad exclusion can hide an entire group of hosts from the coverage report.

Detection and alert records with triage tickets

Logs of malware detections, blocked events and failed remediations exported from the console, each linked to a ticket that shows who triaged it, what action was taken and when it closed. Central management only matters if detections reach someone who acts on them. Sample a set of detections and confirm that each has a ticket with a resolution, and that repeated detections on the same host trigger a deeper investigation. Where the anti-malware console forwards events to a central log platform, reference the Control 8 records to show continuity.

Console administrator access records

The list of accounts that can change policy, exclusions or device group assignments, the role each holds, and the audit trail of their actions. Because a console administrator can disable protection across the fleet, this is a high-value control point. Confirm that administrator access follows the Control 6 role-based model, that privileged accounts use multi-factor authentication, and that changes to policy appear in a log that someone other than the administrator reviews. Access reviews should be recorded with a date and reviewer.

Host-level cross-checks with osquery and Velociraptor

Independent evidence that the anti-malware process actually runs on hosts, which the console alone cannot prove. osquery can query running processes and installed software across a fleet on a schedule, and Velociraptor can run a hunt that collects artifacts from a group of systems, including machines that reconnect later. Use either tool to confirm that the anti-malware service is present and running on hosts the console reports as healthy. Treat mismatches as findings to investigate, and keep the query definitions and results as evidence of the cross-check.

How to set up central anti-malware management in order

This sequence moves from knowing what you have to proving that every in-scope asset reports to one console with a policy, an exception record and a coverage figure you can show an assessor. Each step depends on the one before it, because Safeguard 10.6 is measured against the inventories and the deployment that Safeguards 1.1, 2.1 and 10.1 establish.

Confirm the asset and software inventories
Before any console is configured, the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) must be current, since the Assessment Specification lists both as prerequisites for measuring 10.6. The IT operations lead or asset owner reconciles the two lists against discovery results and flags devices with no owner or no record. The output is a signed-off inventory with a count of in-scope endpoints, which becomes the denominator for the coverage metric.
Confirm the anti-malware baseline on each asset
Safeguard 10.1 requires anti-malware software on every enterprise asset, and central management can only report on agents that exist. The endpoint or security engineering team checks that the agent is installed, running and updating on each asset class, and records exceptions for systems that cannot run an agent. The output is a deployment list that maps each asset to its agent state, which the console later has to match.
Choose or confirm the central console
Select the management platform that will hold policy, health status and detections, or confirm the one already in use. Whether the console is self-hosted, cloud-hosted or part of a larger security platform is a decision for the organization, and any open-source option should be checked against the agent types and operating systems in the inventory. The output is a written statement of the console, its administrators and its data location, approved by the security owner.
Define policy groups
Group assets by function, such as workstations, servers, laptops and high-value systems, and assign each group a written anti-malware policy covering scan behavior, update source and tamper protection. The security architect drafts the policies and the control owner approves them. The output is a policy catalog that names the group each asset belongs to, so every asset inherits a known configuration from the console.
Enroll all in-scope assets
Connect each asset in the inventory to the console and confirm that it appears with its assigned policy group and a current health status. Assets that do not enroll are reported as exceptions, not silently left out. The output is a fleet list in which every in-scope asset is either enrolled or matched to a documented exception, which is the base for the Coverage measure.
Define the exception process with owners and expiry
Any asset that cannot be centrally managed needs a named owner, a reason, a compensating control and an expiry date for the exception. The control owner approves each exception and reviews the register on a schedule set in the policy. The output is an exception register that shows why each uncovered asset exists and when it must be resolved, so the coverage figure can be explained to an assessor.
Set alert routing and triage ownership
Decide which detections and health alerts go to which team, what severity triggers escalation, and who triages them outside working hours. The security operations lead documents the routing rules and tests one alert end to end to confirm delivery. The output is a routing matrix with named roles, along with a record of the test, which shows that central visibility leads to action.
Produce and retain the first coverage report
Run the first coverage report against the inventory, calculating the share of anti-malware centrally managed, and reconcile any gap against the exception register. The security owner signs the report and stores it with the inventory, policy catalog, exception register and routing matrix. The output is a dated baseline that shows the state of Safeguard 10.6 at the start, and repeating the report on a recurring basis gives the evidence trail an assessor will ask to see.

What central anti-malware management costs to meet

This table breaks down the cost components of meeting Safeguard 10.6, showing who is paid for each, whether it is one-time or recurring, what moves it up or down, and how to reduce it. No prices or durations are stated because none are supplied for this topic, so use the rows to structure a quote request. The main takeaway is that the largest recurring costs follow fleet size, console count and exception volume, not the number of policies.

Cost component	One-time or recurring	What drives it up or down	How to reduce it
Console licenses or hosting	Setup is one-time; licenses or hosting recur	Number of managed endpoints, number of consoles, and whether the console is vendor-hosted or runs in your own environment	Consolidate to one console where practical, and confirm license tiers per device before buying more capacity
Engineering time to enroll and configure	One-time, with ongoing effort for new asset classes	Operating system mix, number of asset groups, and how cleanly asset inventory from Safeguards 1.1 and 2.1 feeds enrollment	Build enrollment from a current asset inventory, and standardize policy groups so new devices inherit settings automatically
Policy and console configuration upkeep	Recurring	Number of policy variants, frequency of change, and how many teams approve changes	Keep a small set of baseline policies with documented exceptions rather than per-team variants
Exception and coverage report upkeep	Recurring	Number of unmanaged or excluded assets, and how often coverage is reviewed (the assessment specification measures the share of anti-malware centrally managed)	Track exceptions with owners and expiry dates, and reconcile console coverage against the asset inventory on a fixed schedule
External review of policy and evidence	Recurring when scheduled, or one-time for a readiness review	Scope of the review, number of consoles covered, and whether the reviewer also tests evidence or only reads documents	Ask for a fixed-scope review with a written list of artifacts checked, and reuse the same evidence pack for later reviews
Auditor sampling effort	Recurring with each audit cycle	Number of assets or consoles the auditor samples, and how easily you can produce console exports for the sample	Keep dated console exports, coverage reports and exception logs in one retrievable location before the audit starts
Self-hosted tooling in place of some license spend	Setup is one-time; hosting and maintenance recur	Whether the open-source tool covers the telemetry you need, and how much internal staff time it takes to run	Confirm that the tool answers the same coverage and status questions your auditor will ask, and budget for operation, not just installation

How osquery and Velociraptor can check fleet coverage

Safeguard 10.6 asks the enterprise to manage anti-malware centrally, but a console only shows what its agents report. A separate check helps confirm that the anti-malware process is actually running on every asset the console claims to cover. osquery can do this by exposing running processes, loaded kernel modules, open network connections and file hashes as SQL tables that a team can query on each host. Its osqueryd daemon schedules those queries and runs them across an entire fleet, so a team can ask one question, such as whether the endpoint protection process is present and what its binary hash is, and compare the answers with the console's list of managed devices. Devices that appear in the osquery results but not in the console, or that run the process without a matching console record, are the gaps this check exists to find. The osquery licence is Apache-2.0 OR GPL-2.0-only, which the team should confirm against its own distribution and internal policy before deployment.

Velociraptor takes a complementary approach. It collects forensic artifacts defined in VQL from endpoints, and its hunts collect one or more artifacts across a group of systems at once. Hunts can be scoped to the device population the console reports, so the team can see which systems return the anti-malware artifacts and which do not. Machines that are offline when a hunt starts are scheduled to collect when they reconnect, which matters for laptops and remote staff who are often outside the console's check-in window. Each hunt also gets a notebook for analyzing the combined results, which gives reviewers a dated record they can keep as supporting evidence. Velociraptor is licensed under AGPL-3.0-only, so the team should confirm how that licence applies to its use before relying on it in production. Both tools verify the central console and do not replace it. They cannot apply policy, push signature updates or quarantine a detection, and a clean query result does not prove that the anti-malware software is configured correctly. Before deployment, confirm with the console vendor which process names, service states and version fields it reports, decide how often the queries run, and agree who reviews the differences. Retain the query definitions, hunt results and notebooks with the console export so an assessor can trace the coverage figure back to the underlying data.

Doing central anti-malware management in-house or with a partner

Your organization owns Safeguard 10.6. The control belongs to you, so the console, the policy it enforces and the decisions made from its data should sit with people accountable for security. A partner can build and document the setup, but day-to-day operation, exception approval and alert triage remain internal decisions that an assessor will ask you to explain.

Console ownership: Assign named administrators for the central anti-malware console, with a documented owner for changes to policy and to the list of managed assets.
Policy and exceptions: Approve the baseline policy and record every exception with a reason, an owner and an end date.
Alert triage: Define who reviews detections, how quickly, and how a confirmed detection moves into incident handling.
Coverage review: Check on a set schedule that the share of centrally managed anti-malware matches the asset inventory from Safeguards 1.1 and 2.1.
Operating records: Keep change logs, review notes and exception approvals, because these are the records an assessor samples.

Before engaging anyone, confirm that you can name the person who answers for each of these items.

Where central anti-malware management usually falls short

Central management under Safeguard 10.6 is only as good as the records behind it. The gaps below are the places where a console can look complete while the fleet is not covered, configured or reviewed as the Safeguard expects. Each card names the check to run and the action that closes it.

Unmanaged assets missing from console records

Devices that never enrolled in the console do not appear in its coverage numbers, so the console can report full coverage while parts of the fleet sit outside it. Compare the console's enrolled host list against the enterprise asset inventory that Safeguard 1.1 requires, which the assessment specification also treats as a prerequisite for 10.6. Close the gap by enrolling or retiring every unmatched asset and recording who owns that decision.

Agents installed but not reporting

An agent can be present on a device yet silent because its service stopped, its certificate expired or its check-in path is blocked. These devices look protected in an install count but contribute nothing to the Coverage metric. Check last-seen timestamps and agent health for each enrolled host, and treat any host that has not checked in within the console's own threshold as uncovered until it reports again.

Policy drift across groups

Over time, policy groups accumulate one-off changes: a scan exclusion added for a build server, a relaxed setting for a lab subnet, or an older policy left attached to a retired group. The result is that similar devices receive different protection. Export each group's effective policy on a fixed schedule, compare it with the approved baseline, and record every difference as an approved exception or a defect to fix.

Exceptions with no owner or expiry

Scan exclusions and disabled features are often granted for good reasons and then forgotten. Without a named owner, a business reason and an end date, an exception quietly removes protection from part of the fleet for years. Require every exception to carry those three fields in the change record, review open exceptions at a set interval, and remove any exception whose owner cannot justify it again.

Alerts with no triage record

Detections that are seen but never assigned, closed or escalated give the appearance of monitoring without proof of it. An assessor looking at central management will ask what happened to each detection, not just how many appeared. Set a triage workflow with an owner, a status and a closure reason for every alert, and keep the record so that a sample of detections can be traced from alert to outcome.

No coverage report retained over time

A console dashboard shows the current state, but it rarely shows how coverage changed last quarter. Without retained snapshots of the Coverage metric, a team cannot demonstrate consistent operation or explain a dip. Export coverage and policy status on a regular cadence, store the reports in an evidence repository with access controls, and confirm the retention period with your own audit and records policy before relying on the console's default history.

What buyers ask about cost, effort and timing for Safeguard 10.6

Do IG1 organizations have to meet Safeguard 10.6?

No. CIS Controls v8.1 places Safeguard 10.6 in Implementation Group 2, so it applies to IG2 and IG3 enterprises and sits outside the IG1 baseline. IG1 is CIS's essential cyber hygiene set and the minimum standard for every enterprise, with 56 Safeguards in total. Safeguard 10.1, which deploys anti-malware software on every enterprise asset, belongs to that baseline, so an IG1 organization should confirm 10.1 is met before anything else. Central management becomes relevant when your enterprise moves into IG2 scope, when a customer, regulator or contract asks for it, or when your fleet has grown beyond what separate endpoint consoles can show clearly. Confirm your Implementation Group through your own risk assessment, because that choice decides which Safeguards your assessor will test.

Can our own team implement Safeguard 10.6 without an outside partner?

Often yes, if the team has the time and skills. The organization owns its controls, so internal staff can configure the console, write the policy and collect the evidence. The practical first step is to confirm the prerequisites are measurable: the enterprise asset inventory under Safeguard 1.1, the software inventory under Safeguard 2.1 and the anti-malware deployment under Safeguard 10.1. If any of those are incomplete, the Coverage figure for 10.6 is hard to defend because its denominator is unclear. An outside partner can prepare systems, document settings and assemble evidence, which helps when engineers are stretched or have not run a central console before. Whichever route you choose, an independent assessor reviews the result, and an implementation partner does not issue reports or certificates. Ask who will hold console administration rights after handover.

What drives the cost and effort of central anti-malware management?

Cost comes from four places: the anti-malware product and any console licensing, the labor to deploy and configure the console, the time to reconcile the asset inventory with what the console reports, and the ongoing review of coverage and detections. Your existing vendor agreement or procurement choice sets the product cost, and DeployOpen does not set that price. Effort rises with the number of endpoints, the mix of operating systems and locations, the number of policy variants, and the number of devices that reach the console through gaps such as offline or unmanaged systems. One-time work includes design, initial rollout and documentation. Recurring work includes policy changes, exception handling, license renewals and periodic evidence collection. The cost table on this page groups these components. When you request a quote, ask for each component as a separate line, the assumed asset count, what is one-time and what recurs, and which items depend on your licenses.

How long does centralizing anti-malware usually take?

The supplied facts do not give a duration for this work, so no timeline should be taken from this page. Duration depends on how many enterprise assets are in scope, how complete the inventory is, how many anti-malware products are already in use and how many change windows your operations team allows. Environments with a clean inventory and one product generally move faster than those consolidating several consoles, although that is a qualitative pattern and not a measured figure. What to confirm is the schedule in the written scope: the phases, the milestone that marks console coverage, the point at which evidence is delivered and which tasks wait on your change approvals. Ask the partner to name your dependencies, such as console access, approval windows and user communication. A fixed-scope engagement sets timelines in writing before work starts, so compare proposals on the milestones each one commits to.

What does central anti-malware management need from our staff?

Expect several named roles. An endpoint administrator manages the console, deploys agents and maintains policy. A security operations owner reviews detections, sets alert triage and approves exceptions. The asset inventory owner keeps the device list accurate, because the coverage measure depends on it. A change approver signs off on policy changes that could affect production systems. These roles matter after the project as well as during it. Plan for periodic review of the coverage measure, handling of devices that drop out of management and evidence collection for your assessor. Staff time for these tasks recurs, so ask each quote to show post-launch operations hours as a separate line. If your team lacks one of these skills, name the gap in the scope and confirm who makes the final decisions, since the organization remains accountable for its controls.

How do we scope a fixed-scope engagement for Safeguard 10.6?

Start by listing what is in and out, then tie each deliverable to something a reviewer can check. Describe the asset population: device classes, operating systems, locations, and any cloud or remote endpoints. Name the anti-malware products and consoles in scope, and state which prerequisites under Safeguards 1.1, 2.1 and 10.1 the partner will verify and which you will keep. Define deliverables such as the documented central policy, the console configuration record, the coverage report and an evidence index. Set the measure explicitly. The CIS Controls Assessment Specification for Safeguard 10.6 scores the share of anti-malware centrally managed, so the scope should say how that share is calculated and who approves it. List client responsibilities, including access, approvals and staff time, and agree how scope changes are handled in writing. Ongoing monitoring or testing can be covered by a separate retainer.

Does an implementation partner issue a CIS Controls certificate?

No. The CIS Controls have no certification that a partner can issue. CIS makes the Controls free for organizations to use to improve their own cybersecurity, and CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. A partner such as DeployOpen prepares systems, documentation and evidence for review. Only an independent auditor, assessor or certification body issues a report or certificate under the framework that requires it. If a customer or regulator asks for evidence against Safeguard 10.6, ask which framework they mean. The CIS Controls Navigator maps 10.6 to NIST SP 800-53 Rev. 5 control SI-3, ISO/IEC 27001:2022 Annex A control 8.7 and SOC 2 criterion CC6.8, and each of those assessments has its own scope and test procedures. Confirm with the assessor which mapping they will test before the engagement starts.

How DeployOpen scopes and prepares central anti-malware evidence

DeployOpen helps organizations prepare the systems, configuration and evidence behind Safeguard 10.6, the central management layer over per-asset anti-malware deployment. The organization keeps ownership of its controls, and an independent assessor makes any determination about them.

How we scope

Confirm the Implementation Group in scope, since 10.6 applies to IG2 and IG3 enterprises only.
Record which anti-malware products, consoles and asset classes fall within the Coverage measurement.
Agree prerequisite inventories from Safeguards 1.1, 2.1 and 10.1 as part of the written scope.

How we build

Configure a central management console so policy, status and detection data reach one place.
Set up reporting that shows the share of anti-malware instances managed centrally across the fleet.
Test that unmanaged or disconnected endpoints appear in reports and can be brought under management.

How we hand over

Document the console configuration, policy baselines and the procedure for measuring Coverage.
Deliver exported reports and configuration records that map to the evidence your assessor requests.
Walk your security and operations staff through the runbook so the process runs without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review console coverage and policy drift on the schedule agreed in the written scope.
Confirm with your auditor which evidence format and retention period they will accept before work starts.