What the CIS secure configuration management policy template requires
If a customer, contract or regulator asks for CIS alignment on secure configuration, the answer starts with the *CIS Secure Configuration Management Policy Template*, which CIS publishes free of charge. It was developed by a CIS working group, aligns with CIS Controls v8 and v8.1, and addresses only IG1 Safeguards. It covers Safeguards 4.1, 4.2, 4.7, 9.1 and 12.1, which span Controls 4, 9 and 12. The template is a starting point for your own written policy, not a finished compliance document, and your organization owns the policy it adopts, approves and enforces.
The template asks for a documented secure configuration process for end-user devices (mobile included), IoT devices, servers, operating systems and applications under Safeguard 4.1, and a separate documented process for network devices under Safeguard 4.2. Both must be reviewed once a year or after significant enterprise changes. Safeguard 4.7 requires you to deal with vendor-supplied default accounts such as root and administrator, for example by disabling them or making them unusable. Safeguard 9.1 limits execution to fully supported browsers and email clients at the latest vendor-supplied version. Safeguard 12.1 requires network infrastructure to be kept up to date. Confirm the exact wording of each Safeguard against the CIS Controls v8.1 materials before you cite it to an assessor.
Cost and effort depend mainly on how many systems, sites and cloud accounts the configuration process must cover, and how many teams maintain them. Writing the policy is a one-time task, while the yearly review, the annual or post-change updates and the evidence collection recur. Internal staff may draft the policy, but an implementation partner can be asked to scope the asset types, prepare baseline configurations and collect evidence in your own environment. Any written quote should state which asset classes, sites and platforms are in scope, who approves the policy, how many review cycles are included, and what evidence is delivered. The CIS Controls Assessment Specification defines how Safeguard 4.1 is scored, so ask any assessor how they will test the review date.
What a CIS secure configuration policy engagement costs and who is paid
This table separates the cost components of a CIS secure configuration program by who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. Use it to plan internal effort, scope an implementation partner and decide whether an independent assessor is needed. The main takeaway is that most of the cost sits in internal ownership and recurring review, and no published price exists for the policy work itself, so request a written scope quote.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Policy ownership and approval | Internal owners, such as IT operations or the CISO's team, and an executive approver | Recurring, at least yearly review under Safeguard 4.1 | Number of enterprise asset types, change frequency and the number of approval layers |
| Configuration standards and baselines | Internal engineers, with optional help from a hardening partner | One-time build, then recurring updates | Choice of CIS Benchmarks or vendor baselines and the number of operating systems and applications in use |
| Hardening and evidence preparation | Implementation partner under a written, fixed scope, or internal staff | One-time for the initial hardening, recurring for drift checks and re-evidence | Count of device types, network devices, cloud accounts and whether configuration is automated |
| Tooling for configuration checks | Open-source tools are often free to license, but staff time and hosting are paid | Recurring for hosting, maintenance and upgrades | Coverage needed across endpoints, servers, network gear and cloud, and the skills available in house |
| Network device and infrastructure currency | Network staff, vendors for support contracts, or a managed service provider | Recurring, tied to vendor support lifecycles | Number of network devices, vendor support terms and whether a supported network-as-a-service option is chosen |
| Independent assessment, if required | Independent auditor, assessor or certification body, not the implementation partner | Usually one-time per assessment cycle, repeated when the cycle recurs | Scope of the assessment, the contracting framework and the assessor's own fee terms |
| CIS Controls Accreditation application | CIS and CREST, for accreditation of CIS SecureSuite member services | One-time application fee for the accreditation process | Application fee of $1,500 for CREST members and $2,500 for non-members, as listed by CIS |
What makes the secure configuration work larger or smaller
The effort behind a CIS-aligned secure configuration policy rises or falls with a handful of inputs: how many assets and sites exist, how many browsers and mail clients are in use, how current the baseline is, how often change happens and how well vendors support the platforms. Each card below names one driver and the check that keeps it under control.
Enterprise asset count and type
Safeguard 4.1 covers end-user devices including mobile, IoT devices, servers, operating systems and applications. Each class needs its own hardened baseline, so a fleet with laptops, phones, cameras and virtual servers needs more configuration work than a single device type. Build an asset list by class from the Control 1 inventory, then confirm which classes have a documented standard configuration and which have none.
Network devices and sites
Safeguard 4.2 requires a written process for configuring network devices securely. Every additional site, branch office or cloud network adds routers, switches, firewalls and access points that each need a configuration standard and a review cycle. Ask for a count of devices per site and confirm that each device family maps to a documented standard before the policy is approved.
Browsers and email clients in use
Safeguard 9.1 allows only fully supported browsers and email clients, at the latest version the vendor supplies. Each product and version in use is another item to track, test and retire. Reduce the count where possible, then record the approved versions and the process that removes anything the vendor no longer supports.
Current configuration baseline
The Safeguard 4.1 assessment scores the process as failing when it was last reviewed and updated more than 12 months ago. An organization with a recent, approved baseline for each asset class needs less rework than one that is building standards from scratch. Check when each baseline was last reviewed, who approved it and whether a scan confirms that systems match it.
Change frequency
Frequent changes to operating systems, applications, cloud templates and network rules make a baseline drift faster. Each significant enterprise change is a trigger for review under Safeguard 4.1 and Safeguard 4.2, so a high change rate means more review events each year. Record the number of changes per quarter by asset class and link them to the baseline review log so the trigger is visible.
Vendor support status
Safeguard 12.1 asks for network infrastructure to run the latest stable release or a currently supported service. Devices or software that a vendor has ended supporting force either an upgrade or a documented exception. List every platform with its vendor support end date, since an unsupported item affects several Safeguards at once and is often the costliest driver to fix.
How each Safeguard is written into policy and tested
Safeguard 4.1 asks for a written process for configuring enterprise assets securely. The process must cover end-user devices, including mobile devices, IoT devices, servers, operating systems and applications, and it must be reviewed once a year or after significant enterprise changes. The Assessment Specification scores this Safeguard as failing when no secure configuration process exists or when the process was last reviewed and updated more than 12 months ago. Its metric is standard configuration coverage, so the question is how much of the estate follows the documented standard. CIS describes what to measure, not how, so your team must decide the sampling method and tooling.
- Scope statement: Name each asset class the process covers, including mobile and IoT, and state which baseline applies to each.
- Review record: Show the version history, approval date and the trigger for any out-of-cycle review after a significant change.
- Coverage evidence: Export configuration compliance reports from your configuration management or scanning tooling, showing the share of assets on the standard build.
- Exception register: Record each deviation from the standard, with an owner, a reason and an expiry date.
Confirm with your assessor how they will sample assets and which coverage threshold they accept, because the Assessment Specification does not state how coverage is calculated.
Safeguard 4.2 asks for a written process for configuring network devices securely. It follows the same annual and post-change review rhythm as Safeguard 4.1, but it is aimed at routers, switches, firewalls and wireless controllers rather than endpoints and servers. The policy should make clear who approves a network device build, how management interfaces are secured and how changes to running configuration are recorded. Because network device configuration often lives in several places, the policy should name the authoritative source for each device class.
- Device classes: List routers, switches, firewalls, load balancers and wireless controllers, each with its hardening baseline.
- Change control link: Require that configuration changes to network devices pass through the same review step used for other production changes.
- Backup of configurations: Store current and previous configurations in a controlled location with access restricted to authorized staff.
- Review evidence: Keep the dated review record and the list of devices reviewed against the current baseline.
Illustrative example: a firewall rule set exported and compared against the approved baseline each quarter gives an assessor a clear trail, but the policy must still state the annual review cycle that the Safeguard requires.
Safeguard 4.7 requires the enterprise to deal with default accounts that vendors ship preconfigured, such as root and administrator accounts. The policy should state the method used for each account type, for example disabling the account or making it unusable, and say who approves any exception. The Assessment Specification checks whether default accounts are managed in this way, so the policy must cover the platforms in your estate, including appliances, databases, cloud services and network devices where default credentials are common. Confirm the exact measures with the current Assessment Specification before you build the evidence pack.
- Default account list: Maintain an inventory of vendor default accounts for each platform, with the action taken on each.
- Disable or rename method: Document the method per platform, since some accounts cannot be removed and must be made unusable.
- Credential rotation: Record that any default password was changed at deployment and that the new value is held in a managed secret store.
- Exception approval: Require a named owner and a dated approval for any default account left active.
Ask your assessor which platforms they will sample first, because a single appliance with an unmanaged default account can fail the check even when the rest of the estate is clean.
Safeguard 9.1 allows only fully supported browsers and email clients to execute in the enterprise, and only at the latest version supplied by the vendor. The policy should name the approved browsers and email clients, state the vendor support status that qualifies them and require that unsupported versions are blocked or removed. This Safeguard sits under Control 9, so the policy also needs a method for checking installed versions on managed endpoints and a rule for how quickly updates are applied. Because the policy names specific products, it will need revision as vendors change their support lifecycles.
- Approved list: Name each browser and email client permitted in the enterprise, with the vendor support end date you rely on.
- Version enforcement: Describe how the latest vendor version is deployed, whether by automatic update or managed rollout.
- Blocking rule: State how unsupported or unapproved browsers and mail clients are prevented from running on managed devices.
- Inventory evidence: Export software inventory results from endpoint management showing installed browser and email client versions.
Confirm with your assessor whether they will test unmanaged devices that connect to corporate email, since the policy scope determines what the inventory must cover.
Safeguard 12.1 asks for network infrastructure to be kept up to date, for example by running the latest stable software release or by using currently supported network-as-a-service offerings. The policy should set the rule for patching and upgrading network devices, the criteria for deciding when a platform is no longer supported and the owner of each decision. The Assessment Specification checks whether network infrastructure is current, so the evidence must show installed versions against the vendor's current release or support status. Where a device cannot be upgraded, the policy should require a documented risk decision and a replacement plan.
- Version register: Keep a register of each network device with its firmware or software version, support end date and owner.
- Upgrade rule: State how often the register is reviewed and how quickly a vendor security release must be assessed.
- Unsupported device process: Require a risk acceptance and a dated replacement plan for any device past vendor support.
- Upgrade records: Keep change tickets and test results for each network software upgrade.
CIS Benchmards, which provide prescriptive hardening guidance, help define the target configuration after an upgrade, but they do not replace the version check itself. Confirm the reference release your assessor will treat as current.
How to draft, approve and evidence the policy in sequence
This sequence turns the CIS secure configuration template into an approved, published policy with dated proof that Safeguards 4.1, 4.2, 4.7, 9.1 and 12.1 are being met. Each phase produces a document or record that an assessor can trace back to a Safeguard.
Adopt the template and scope it to assets
Start from CIS's free IG1 Secure Configuration Management policy template and narrow it to the enterprise assets in play: end-user devices including mobile, IoT devices, servers, network devices, operating systems, applications and browsers or email clients. Record which asset classes are out of scope and why, so the boundary is explicit. The output is a scoped draft with a written asset boundary that the policy owner can defend. Confirm the scope and any timing with your implementation partner in the written scope before drafting begins.
Assign named owners for each Safeguard
Assign one accountable owner for the overall configuration process (Safeguard 4.1), one for network device configuration (Safeguard 4.2), one for default account handling (Safeguard 4.7), one for browser and email client currency (Safeguard 9.1) and one for network infrastructure updates (Safeguard 12.1). Owners should be roles with authority to change builds and approve exceptions, not only the people who run the tools. The output is a responsibility table that names each owner and their deputy.
Map the policy to existing standard builds
Inventory the baseline images, golden templates, configuration management code and vendor hardening documents your teams already use for each asset type. Compare them against the policy's requirements and record gaps, such as servers without a documented baseline or network devices managed only by hand. Where a CIS Benchmark is the chosen reference, note which profile applies to each platform. The output is a mapping sheet linking each standard build to the Safeguard it supports, with gaps assigned to owners.
Approve and publish the policy
Route the scoped draft through the people who must accept it: the security lead, IT operations, the owners named in the previous step and the executive who carries the risk. Record approval with the version number, approver names and the approval date, then publish it where engineers and auditors can find it. Exceptions process should be part of the approved text so that deviations are documented rather than silently tolerated. The output is an approved, versioned policy with a dated approval record.
Run the first configuration review
Sample the in-scope assets against the approved baselines and record deviations, unsupported browsers or email clients, vendor default accounts still active, and network infrastructure running unsupported software. Compare the results with the metric the CIS Controls Assessment Specification uses for standard configuration coverage. Assign remediation tickets with owners and target dates set in your own plan. The output is a dated review report with a deviation log and remediation tracking.
Collect dated evidence for each Safeguard
For each Safeguard, gather the records an assessor will ask for: the approved policy and its approval date, baseline definitions, configuration scan or compliance reports, disabled or renamed default account records, browser and email client version inventories, and network device patch records. Store them in a single evidence register with collection dates and the name of the person who produced each item. The output is an evidence register that lets an assessor trace each claim to a dated artifact. Confirm with your auditor which evidence formats they accept.
Schedule the yearly review and change triggers
Book the annual review of the policy and its Safeguard 4.1 and 4.2 processes, and add a trigger so the policy is also reviewed after significant enterprise changes, such as a new platform, cloud migration or acquisition. Assign the review owner and add the review date to the evidence register. The output is a review calendar entry and a change log that show the policy stayed current. Set the cadence and deadlines in the written scope so they match your governance cycle.
Where CIS Benchmarks fit in a configuration process
The policy sets the requirement, and a CIS Benchmark is one of the ways an organization can meet it. Safeguard 4.1 asks for a written process for configuring enterprise assets securely, and Safeguard 4.2 asks for the same for network devices. Neither asks for a specific Benchmark. The policy should name the owner of the process, the asset types it covers (end-user devices including mobile, IoT devices, servers, operating systems and applications, and network devices), and the point at which a configuration baseline must exist before a system goes into production. CIS Benchmarks are prescriptive configuration recommendations for system hardening. CIS develops them through a consensus-based process in which volunteers, subject matter experts, vendors and community members discuss drafts on CIS WorkBench until consensus is reached. That origin matters to a reviewer because it explains what a Benchmark is: a published starting point, not a statement of what your environment must look like.
A Benchmark is therefore one input the organization may adopt, and the decision to adopt it, choose the right profile and tailor it remains the organization's own. Benchmarks publish profiles, so the owner should decide which profile fits each asset class and record the reason, including any setting that is changed, deferred or accepted as an exception because a business application depends on it. Confirm the Benchmark versions and profiles you intend to use against the current listings on the CIS Benchmarks pages before you cite them in the policy, since versions change. Where no Benchmark exists for a platform, the policy still needs a documented baseline, which may come from a vendor guide, an internal standard or a tailored Benchmark. The assessor will look for the decision record, not for a particular brand of hardening guide. Keeping that record current is what lets the yearly review required by the policy show that configurations still reflect the organization's risk decisions.
What must be in place before an assessor reviews the policy
An assessor will test the secure configuration policy against the systems it describes, not just the document. The items below connect the written process to the evidence that proves it runs, so each can be checked before anyone outside the organization looks at it.
Approved and dated policy
The Safeguard 4.1 process must exist as a written document with an approver, an approval date and a version history. Assessors score the process as failing when none exists or when the last review is more than 12 months old, so the date on the document is the first thing they check. Confirm that the approver holds authority over IT operations and that the policy names the enterprise assets it covers, including end-user devices, mobile devices, IoT devices and servers.
Named owners for each process
Each part of the policy needs a named owner: the secure configuration process under Safeguard 4.1, the network device process under Safeguard 4.2, default account handling under Safeguard 4.7, and browser and email client support under Safeguard 9.1. Ownership should appear in the policy and in the team's own records. Confirm that each owner can explain the process and point to the evidence it produces.
Current standard builds per device class
Assessors measure standard configuration coverage, so the organization needs a documented build for each device class such as workstations, servers, mobile devices and network appliances. Each build should reference a hardening baseline, such as a CIS Benchmark where one fits, and record the exceptions approved for it. Check that every build has a version and review date, and that a sample of live systems matches the build they claim to follow.
Network device and default account inventories
The network device process under Safeguard 4.2 and the default account requirement under Safeguard 4.7 both depend on accurate inventories. Pull the network device list from the asset inventory built under Control 1 and the software list from Control 2, then confirm that each device lists its configuration baseline. For default accounts, check that vendor-supplied accounts such as root and administrator are disabled or otherwise unusable on every device in the list.
Record of the most recent review
The policy calls for review once a year or after significant enterprise changes, so the file should hold a dated record of the last review and a list of the changes that triggered any earlier review. Minutes, a signed review sheet or a ticket in the change system all serve as evidence. Confirm that the record shows what was checked and what changed, not only that a review took place.
Proof that browsers and email clients are supported
Safeguard 9.1 allows only fully supported browsers and email clients, and only at the latest version the vendor supplies. Produce a list of every browser and email client in use, its installed version and its vendor support status, then compare that list against the vendor's current release. Any exception needs a documented business reason, a compensating control and an end date. Ask IT to show the software inventory export that supports the list.
Who owns the policy, who prepares evidence and who reports
The organization is accountable for the secure configuration policy and for every Safeguard it claims to meet. CIS states that the Controls are free for any organization to use to improve its own cybersecurity, and the CIS policy templates are written for IG1 use. Adopting them is an internal governance decision, not something an outside firm can perform on the organization's behalf. Leadership must approve the policy, name an owner for the configuration process and decide which systems fall in scope.
- Policy approval: A named executive or governance body approves the policy, and the approval date and version are recorded.
- Process ownership: One role owns the documented configuration process required by Safeguard 4.1 and is accountable for its yearly review.
- Risk decisions: The organization decides which deviations from a hardened baseline it accepts, who approves them and how long they last.
- Scope statement: The organization defines which end-user devices, servers, network devices and browsers are covered.
- Attestation: Staff who sign internal statements about control operation are employees of the organization, not the partner.
Before engaging anyone, confirm that the policy owner can state the scope and the review cycle without reading the document.
An implementation partner such as DeployOpen can plan, implement, harden, document and support self-hosted open-source platforms inside the client's own infrastructure. For this policy, that work typically means building configuration baselines, applying hardening to operating systems and applications, disabling or renaming vendor default accounts, setting up patch and version tracking for network infrastructure, and producing the records that show these steps happened. The partner prepares systems and evidence. It does not decide that the organization is compliant.
- Baseline build: Configuration standards are drafted for the platforms in scope, with CIS Benchmarks used as a reference where they exist.
- Default account handling: Vendor-shipped accounts are identified, disabled or made unusable, and the change records are kept.
- Evidence capture: Configuration exports, scan outputs, change tickets and version inventories are organized for the assessor.
- Documentation: Runbooks and the configuration process document are drafted for the organization's approval.
- Ongoing support: Where agreed, a retainer covers upgrades, re-hardening and periodic re-checks.
Ask for the written scope, the list of deliverables and who approves the final documents before work starts. Most engagements are fixed-scope, so these items should be agreed in writing.
Only an independent auditor, assessor or certification body issues a report, attestation or certificate. This is the independence boundary. An assessor tests the organization's controls against the evidence and states its conclusion. If the same firm designed the controls, built the systems and then certified them, the conclusion carries little weight with a customer, a regulator or an accreditation body. The CIS Controls Assessment Specification defines what to measure for each Safeguard, but it is the assessor's testing and judgment that produce a finding.
- Separation of duties: The firm that prepares evidence should not also issue the report on the same controls.
- Assessor selection: Confirm the assessor's accreditation or qualification for the relevant scheme before signing.
- Sampling: Expect the assessor to sample systems and records rather than accept a single export.
- Report ownership: The report is addressed to the organization, and the organization decides who receives it.
- Accreditation caution: CIS Controls Accreditation applies to CIS SecureSuite member organizations offering implementation, auditing or assessment services, so check whether a firm holds it before relying on that claim.
Ask the assessor in writing which evidence it will test and which parts of the process it will not perform itself.
Organizations usually outsource the labor-heavy and technical parts of secure configuration: baseline builds, hardening, evidence collection and the first documentation drafts. They usually keep policy approval, risk acceptance, exception decisions and the operation of the configuration process after handover. Cost follows this split. Implementation effort is typically a one-time cost, while patch tracking, benchmark re-checks and yearly reviews recur. The organization pays the partner for preparation work and pays the assessor separately for testing and reporting.
- Outsourced: Hardening of operating systems, applications and network devices, default account remediation and configuration exports.
- Shared: Writing the configuration process document, where the partner drafts and the organization edits and approves.
- Kept in house: Ownership of the yearly review, risk acceptance and the decision to take an exception.
- Recurring cost drivers: The number of platforms, how often vendors release updates and how many systems fall outside automated management.
- Quote items: Ask for the number of platforms in scope, the deliverables, whether re-hardening after upgrades is included and the handover format.
Confirm before signing which of these items the quote covers and which remain with your team.
Questions buyers ask about the CIS secure configuration policy
Can our team write a CIS secure configuration policy without outside help?
Yes, most organizations can write it internally, because the CIS policy templates are free and already cover the Safeguards. The policy must still describe your real process: which operating systems, end-user devices, mobile devices, IoT devices, servers, network devices and applications you configure, who approves baselines and how exceptions are handled. The hard part is usually not the wording but proving the process runs. Teams that lack an owner for configuration baselines, or that have no way to show deployed systems match them, often ask a partner to help with the technical evidence while they keep ownership of the policy itself.
How much effort does a secure configuration policy take, and what drives it?
The effort depends on how many asset types you run and how documented your current build process is. The policy text is typically the smaller task. The larger work is inventorying the platforms in scope, defining a baseline for each, and collecting evidence that systems follow it. Effort rises with heterogeneous estates, many cloud accounts, legacy network gear and little existing configuration management. It falls when you already use golden images, infrastructure as code or a hardening benchmark. Ask any provider for a written scope listing the platforms, environments and evidence they will deliver before you agree on a figure.
Is the CIS policy template free, and what does the license allow?
The CIS policy templates are free to use. CIS states that the CIS Controls are free for any organization to use to improve its own cybersecurity. The Controls content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, and commercial use requires CIS's prior approval. In practice, your organization can adopt and adapt the template internally for its own security program. If you plan to resell the policy, package it as a service, or publish a modified version commercially, confirm the terms with CIS first and read the license text directly.
Is IG1 enough for secure configuration under CIS Controls?
IG1 is the minimum standard that CIS describes as essential cyber hygiene for every enterprise, and the policy template is built to cater exclusively to IG1 Safeguards. Whether it is enough depends on your risk. Organizations with more operational complexity, sensitive information or regulated assets are expected to look at IG2 Safeguards, and IG3 targets enterprises with security specialists facing sophisticated, targeted attacks. The template does not address IG2 or IG3 Safeguards, so you will need to extend the policy yourself if your assessment or contract points beyond IG1. Also note that CIS states the Controls do not replace any regulatory or compliance scheme.
How often must the secure configuration policy be reviewed?
Safeguard 4.1 asks for the secure configuration process to be reviewed once a year or after significant enterprise changes, whichever prompts review first. The CIS Controls Assessment Specification for v8.1 scores the Safeguard as failing when the process was last reviewed and updated more than 12 months ago. Record the review date, the approver and the changes made, because the assessor will ask to see that history. Trigger an out-of-cycle review after events such as a cloud migration, a new device class or a major operating system upgrade.
What will an assessor ask for to test the secure configuration policy?
An assessor will look for a written secure configuration process, evidence that it was approved and reviewed within the last 12 months, and proof that enterprise assets are configured to it. Expect requests for the policy and its revision history, the list of covered asset types, the baselines or hardening standards in use, and configuration records from a sample of devices and servers. For network devices, expect the same for Safeguard 4.2, and for browsers and email clients under Safeguard 9.1 and network infrastructure under Safeguard 12.1, expect version and support status evidence. Your independent assessor decides what is sufficient, so confirm the evidence list with them before the engagement begins.
Can a partner guarantee that our configuration policy passes an assessment?
No responsible partner can guarantee a pass, because the outcome depends on your systems and on an independent assessor's judgment. DeployOpen prepares systems, controls and evidence for compliance assessments, and it does not issue audit reports, attestations or certifications. What a written, fixed scope can define is the deliverables: the secure configuration process, the baselines for the agreed platforms, hardening of in-scope systems and the evidence package. Ask any provider to specify those deliverables and the timeline in writing, and to explain how they will verify each one against the assessment specification.
How DeployOpen scopes and prepares secure configuration evidence
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so the configuration baseline, review cycle and evidence for Controls 4, 9 and 12 sit where the organization runs its systems. The organization owns its policy and controls, and an independent assessor decides what the evidence proves.
How we scope
- Agree in writing which enterprise assets, operating systems, applications and network devices fall within the secure configuration process for Safeguard 4.1 and 4.2.
- Confirm which browsers and email clients are in use, so the Safeguard 9.1 supported-version list matches what staff actually run.
- Record the network infrastructure inventory and its vendor support status to define the Safeguard 12.1 currency checks.
How we build
- Prepare hardening baselines for in-scope systems, drawing on the CIS Benchmarks where the client has chosen to apply them, and document any deviations.
- Configure removal or disabling of vendor-supplied default accounts such as root and administrator, and record how each was handled under Safeguard 4.7.
- Set up configuration and patch-currency reports that show coverage against the baseline, so the metric in the assessment specification can be read directly.
How we hand over
- Deliver the draft secure configuration process and network device configuration process, written for the client to review, approve and adopt as its own policy.
- Provide a dated review record with a yearly review date and a trigger list for significant enterprise changes, so the reviewer can see the cycle.
- Hand over the evidence pack, including configuration exports, default account records and browser version reports, with a note on what each item does and does not show.
How we support
- Fixed-scope engagements have scope, deliverables and timelines agreed in writing before work starts, and any change goes through a written scope update.
- Ongoing support, upgrades and continuous testing are available as a retainer for keeping baselines and evidence current between review cycles.
- Auditors and certification bodies issue any report or certificate. DeployOpen prepares systems and evidence and does not replace that independent assessment.
