FC-02 · Secure Configuration
Confluence page header block
Page title: FC-02 · Secure Configuration
Parent page: 02 · Fundamental Controls
SCM variants: Default (all-staff) | isms-it-staff | isms-security
Page owner: IT Manager
Last reviewed: [DATE]
Next review: [DATE + 12 months]
Framework mapping panel
Visible to all users. Placed immediately below the page title as a metadata callout.
| Field | Value |
|---|---|
| CMMC Level 1 practice | AC.L1-3.1.22 — Control CUI posted or processed on publicly accessible information systems |
| Cyber Essentials domain | Secure Configuration — all five configuration requirements |
| DEFSTAN 05-138 | Profile 0 (Baseline) — §Secure Configuration and §Software Management |
| ISO 27001 Annex A | 8.9 (Configuration management) · 8.8 (Technical vulnerability management) · 8.19 (Installation of software) · 5.12 (Classification) · 5.13 (Labelling) |
| Related advanced pages | AT-CM · Configuration Management · AT-SI · System and Information Integrity |
| All-staff guidance | 02 · Fundamental Controls → FC-02 (this page) · 01 · Policies → Policy 08 (Change Management) |
| Evidence items (IT/Security) | EV-D19 · EV-D20 · EV-D21 · EV-D22 · EV-D08 |
Why secure configuration is the foundation every other control assumes
All-staff layer — visible to everyone.
Every device we own, every operating system we run, and every application we deploy arrives configured for ease of setup rather than security. Default settings prioritise getting things working quickly. They leave features enabled that are not needed. They set passwords that every attacker knows. They open services that create attack surface. They grant permissions broader than any role requires.
Secure configuration is the process of systematically removing everything that does not belong, setting everything that must be set, and then verifying that the result matches what was intended. It is the control that all other controls assume has been done. An antivirus product running on a system with default credentials and unnecessary services exposed is protecting a building with the front door left open. Fixing the front door is secure configuration.
For the organisation, secure configuration carries weight across three simultaneous compliance obligations. Cyber Essentials lists it as one of five technical controls and assessors test it directly — they check whether default passwords remain, whether unnecessary software is present, and whether automatic updates are enabled. CMMC Level 1 requires that CUI is never exposed on publicly accessible systems, which is ultimately a configuration control. DEFSTAN Profile 0 requires that systems handling OFFICIAL information are maintained in a known secure state with defaults removed and unnecessary services disabled. All three frameworks are asking the same question in slightly different language: is your system running the minimum software, with the minimum permissions, in the configuration that the security team chose rather than the configuration the manufacturer chose?
All-staff layer
No SCM variant wrapper — visible to isms-all-staff, isms-it-staff, and isms-security.
What AC.L1-3.1.22 requires
This CMMC Level 1 practice is one of the four access control requirements that form part of the US Department of Defense baseline for any organisation handling Federal Contract Information. Where the other three Level 1 practices are about who can access systems (AC.L1-3.1.1, 3.1.2) and what external connections are controlled (AC.L1-3.1.20), this one is specifically about what happens at the boundary between our controlled systems and the public internet.
AC.L1-3.1.22 — Control CUI posted or processed on publicly accessible information systems.
The requirement has a precise meaning. A publicly accessible information system is any system reachable from the internet without authentication — our public website, a public API, a customer-facing portal that does not require login before the CUI is visible, a document repository with public access enabled. The control requires that CUI does not appear on any of these systems unless there is a specific, deliberate decision that it should.
In practice, this breaks down into two distinct obligations. First, CUI must not be inadvertently published to public systems — a document containing defence contract specifications published to a public SharePoint link, a database export left in a publicly accessible S3 bucket, an error message that reveals sensitive system information. These are configuration failures, and preventing them is a configuration control. Second, where CUI must be processed on a system that has a public-facing component — a contractor portal that authenticated users access for sensitive documents — the publicly accessible component must be structurally separated from the CUI. The login page is public; the CUI sits behind authentication.
For most staff, the practical obligation from this control is simple: never put CUI on public-facing systems, and if you need to share CUI with an external party, use the approved secure sharing methods described in the User Guidance Hub rather than any public link or publicly accessible platform.
Cyber Essentials — the five secure configuration requirements
Cyber Essentials assesses secure configuration across five requirements that together define the minimum configuration standard for any device, server, or cloud service in scope. Unlike some frameworks that describe the configuration standard in general terms, Cyber Essentials is operationally specific — assessors verify each requirement by examining actual system configurations.
Requirement 1: Only necessary software is installed.
Software that is not needed for the device's function should not be present. This is the principle of least functionality applied to software. Every application installed on a device is potential attack surface — it may have vulnerabilities, it may communicate with external services, it may have its own configuration that creates exposure. The Cyber Essentials requirement is that software present on in-scope devices can be accounted for: there is a reason it is there, and anything without a reason is removed.
For you as a user, this means the software on your company device was put there deliberately. If you need an application that is not already available, the route is to request it through the approved software process. Installing software outside that process puts the device outside the secure configuration baseline.
Requirement 2: Default passwords are changed before any device is deployed.
Manufacturers configure devices with default passwords that are often publicly documented — the default admin password for a common router model is a web search away. Every device deployed in our environment has its default credentials changed before it goes into service. This includes routers, switches, printers, IP cameras, network-attached storage devices, and every other device that has any form of administration interface. For user accounts, there are no shared passwords and no default passwords left in place.
Requirement 3: Unnecessary user accounts are removed or disabled.
Every account on every device has a potential path for attack. Accounts that exist but are not used — default accounts that came with the operating system, accounts created for a purpose that is now complete, accounts for people who have left — are removed or disabled. The same principle applies to service accounts and application accounts.
Requirement 4: Auto-update is enabled or systems are patched within the required timeframes.
Vulnerabilities in software are disclosed continuously, and the time between public disclosure and active exploitation is shrinking. The Cyber Essentials position is that for in-scope devices and software, updates are applied promptly — either automatically where this is technically feasible, or manually within a defined window. Critical security updates must be applied within 14 days of release. Operating systems and applications beyond their vendor support date (end of life) are treated as a compliance failure because no patches are being produced for them regardless of how quickly we apply them.
Requirement 5: Firewalls are configured to prevent unapproved access.
This is the intersection with FC-01 — Cyber Essentials treats firewalls and secure configuration as related domains. The secure configuration element is that every firewall's configuration represents a deliberate, documented decision: what is permitted, from where, to where, and why. A firewall with rules that no one can explain, or with rules that remain from a configuration that predates anyone currently in the organisation, fails this requirement.
DEFSTAN Profile 0 — baseline configuration requirements for defence work
DEFSTAN 05-138 Profile 0 §Secure Configuration sets the minimum configuration standard for any system handling OFFICIAL-tier information. Profile 0 is the starting point — it applies to all our MOD and defence contract work. Contracts specifying Profile 1 or Profile 2 add requirements on top.
Profile 0 requires that all systems handling OFFICIAL information are configured against a documented baseline.
The baseline must be documented — not just implemented. An assessor from the contracting authority should be able to ask what the configuration standard is for a given class of device and receive a documented answer that describes specific settings, specific values, and a specific reference (NCSC guidance, CIS Benchmark, or an equivalent authority). A verbal description of general good practice does not satisfy this requirement.
Unnecessary services, features, and software must be removed or disabled before deployment.
DEFSTAN Profile 0 uses the same principle as Cyber Essentials Requirement 1 and extends it to network services. Any network service that is not required for the system's function must be disabled. Any port that is not required must be closed. Any protocol that has been superseded by a more secure version must not be used. The baseline configuration documentation must capture these decisions explicitly.
Default credentials must be changed on all devices before they are used to handle OFFICIAL information.
This applies equally to network infrastructure (routers, switches, firewalls, access points), servers (the local administrator account, management interface credentials), and applications (any application with a default username and password in its installation documentation). The requirement is absolute — a device with unchanged default credentials cannot be used for OFFICIAL information regardless of any other security measures in place.
Configuration must be maintained — not just set at deployment.
DEFSTAN Profile 0 requires ongoing maintenance of the secure configuration, not just point-in-time compliance. This means: when an operating system or application is updated, the update is reviewed to confirm it has not altered security settings; when a new vulnerability is disclosed, the configuration baseline is checked to confirm the vulnerable feature is disabled or the setting that prevents exploitation is present; and the baseline is reviewed annually at minimum.
Public systems must not process OFFICIAL information unless specifically authorised and controlled.
This is the DEFSTAN expression of the same requirement as AC.L1-3.1.22. Systems that are internet-accessible must not process OFFICIAL information unless the contracting authority has specifically authorised this and the controls around it have been reviewed. In practice, for most of our DEFSTAN work, OFFICIAL information stays on internal systems and the public-facing presence of the organisation does not touch it.
What this means for you — all-staff obligations
Most of what secure configuration requires happens before you receive a device and throughout its life without your involvement. Your obligations are about not undoing the secure configuration that IT Operations has put in place, and about understanding the boundaries that configuration creates.
Do not install software on your company device without IT Operations approval. Every software installation changes the attack surface of your device. Unapproved software bypasses the baseline the IT team has verified, may introduce vulnerabilities not tracked by the patching programme, and creates a device that no longer matches the documented configuration. If you need software that is not available, submit a software request through the helpdesk. The process exists to protect the device without permanently blocking legitimate tools.
Do not change security settings on your device, even temporarily. You may encounter situations where a security setting appears to be preventing you from doing something you need to do — an application that wants to listen for incoming connections, a website that the proxy blocks, a security prompt that appears every time you do a particular task. The correct response in every case is to report the situation to IT Operations, not to change the setting. The settings exist for documented reasons, and changing them creates a device outside the baseline.
Browser extensions are in scope. The approved software obligation extends to browser extensions. Extensions have broad access to your browsing activity, your form inputs, and in some cases the content of web pages including any sensitive information displayed in them. Only approved browser extensions are permitted on company devices. If you have installed browser extensions outside the approved list, they should be removed and the IT Operations helpdesk can help.
Restart when prompted for updates. The update cadence described in the Cyber Essentials requirements above depends on devices being restarted to apply pending updates within the required timeframes. When your device prompts you that a restart is required to complete an update, treat this as a time-sensitive action rather than something to defer indefinitely. The SLA clock for critical patches starts at the date the vendor released the patch, not the date you restart your device.
Do not put CUI on any publicly accessible system. This is the AC.L1-3.1.22 obligation in plain terms. If information is Controlled Unclassified Information — anything from a US defence contract, anything marked CUI, anything you would handle under the CUI procedures described in the information classification training — it does not go on the public website, it does not go in a publicly shared document, it does not go on any system that can be accessed from the internet without authentication. If you need to share CUI with an authorised external party, use the secure sharing methods in the User Guidance Hub.
Report default-looking credentials or security prompts you do not understand. If you are given access to any system — particularly any shared system, any inherited account, or any system that was set up some time ago — and the login appears to use default credentials, or the password you are given is something like "admin" or "password123" or the system name itself, report it to IT Operations before using it for anything work-related.
What to do if something goes wrong
You discover software on your device you do not recognise and did not install. Do not delete it yourself. Note the name and contact IT Operations. Unexplained software on a device may indicate a security incident — IT Operations needs to investigate the installation source and confirm whether the device is still in a known state.
You are prompted to approve an update that seems larger than usual, or that changes the appearance of an application significantly. Apply it. Large updates are often the ones addressing significant vulnerabilities. If you are uncertain whether an update prompt is legitimate, contact IT Operations before approving — do not simply dismiss it.
You accidentally change a setting and are not sure what it was. Tell IT Operations immediately. Do not attempt to reverse the change yourself unless you are certain of the correct value. IT Operations can verify the correct setting from the baseline documentation and restore it correctly.
You find a publicly accessible document, page, or file that appears to contain CUI or OFFICIAL information. Do not assume someone else will notice it. Report it to the security team immediately with the URL or location of the item. The team will assess whether it is genuinely CUI, whether it is genuinely publicly accessible, and what action needs to be taken.
A vendor or supplier asks you to change a security setting on your device so their service will work. Decline and report the request to IT Operations. IT Operations can assess whether the vendor's requirement is legitimate, whether there is a secure way to meet it, and whether the vendor's architecture creates a security concern. You should not make changes on the basis of a vendor's request.
You receive a security notification from your operating system or an installed application saying something is out of date or a setting has changed. Take a screenshot and report it to IT Operations. Do not dismiss the notification without confirming it has been logged.
IT-staff layer
SCM variant: isms-it-staff — visible to isms-it-staff and isms-security.
{scroll-content:variant=isms-it-staff}
Technical implementation — IT Operations
This section provides the implementation detail for AC.L1-3.1.22, all five Cyber Essentials Secure Configuration requirements, and DEFSTAN Profile 0 §Secure Configuration. The full platform-specific baseline specifications are in AT-CM → BL-[PLATFORM] documents and in the FC-02 IT Staff Technical Procedures page. This section covers the configuration governance structure, the publicly accessible system controls, and the Cyber Essentials and DEFSTAN-specific verification procedures.
AC.L1-3.1.22 — Technical implementation
Requirement: Control CUI posted or processed on publicly accessible information systems.
What assessors test: Assessors will request a register of all publicly accessible systems and then verify — either by searching or by asking IT to demonstrate — that none of those systems expose CUI without authentication. They may run web searches for the organisation name combined with known CUI-related terms, or they may request a demonstration that the public website and any associated public assets have been reviewed. They will also check whether cloud storage (S3 buckets, Azure Blob containers, SharePoint external sharing) has been reviewed for public accessibility.
Implementation:
Publicly accessible system register — maintained in EV-D20 as a
dedicated section of the quarterly configuration audit:
Required fields per entry:
System name / URL
Hosting location (on-premises / cloud provider / managed hosting)
Authentication required before content visible: Yes / No / Partial
Last reviewed for CUI: [date]
Reviewed by: [name]
CUI present: No / Yes — [describe and confirm controlled]
Public cloud storage associated: [bucket/container list or "None"]
Review frequency: quarterly (aligned with EV-D20 config audit)
Review method:
Manual: browse every public page and all public-accessible
file paths without authentication
Automated: web crawler run against public-facing URLs
(tool: [Screaming Frog / OWASP ZAP in spider mode / etc.])
Output: list of all publicly accessible content;
analyst reviews for CUI content
Cloud storage:
AWS: S3 Block Public Access enabled at account level (prevents
any bucket from being made public unless explicitly overridden
at account level — override requires CISO approval)
Verify: aws s3api get-public-access-block --account-id [ID]
Expected: BlockPublicAcls:true, IgnorePublicAcls:true,
BlockPublicPolicy:true, RestrictPublicBuckets:true
Azure: Azure Policy — deny public access on storage accounts
Verify: Get-AzStorageAccount |
Select-Object StorageAccountName,
@{N="AllowBlobPublicAccess";
E={$_.AllowBlobPublicAccess}}
Expected: AllowBlobPublicAccess = False for all accounts
GCP: Org policy — constraints/storage.publicAccessPrevention = enforced
M365 SharePoint: External sharing settings at tenant level
SharePoint admin centre → Policies → Sharing:
For CUI sites: set to "Only people in your organisation"
Verify no public/anonymous sharing links have been created
PowerShell check:
Get-SPOSite -Limit All |
Where-Object {$_.SharingCapability -ne "Disabled"} |
Select-Object URL, SharingCapability
Any CUI-scope SharePoint site with sharing enabled = finding
Error message and technical information disclosure:
A category of CUI exposure that is frequently overlooked is technical information disclosed through error messages, HTTP response headers, and directory listings on public-facing web infrastructure.
HTTP response headers — remove or sanitise:
Server: header — do not disclose: IIS/10.0, Apache/2.4.51, nginx/1.21
nginx: add_header Server ""; (in nginx.conf)
IIS: remove via web.config or URL Rewrite module
Apache: ServerTokens Prod; ServerSignature Off
X-Powered-By — remove entirely
X-AspNet-Version — remove entirely
Verify with:
curl -I https://[public-site] | grep -i "server\|x-powered\|x-aspnet"
Expected: no revealing values in any of these headers
Directory listing — disabled on all public web servers:
nginx: autoindex off; (default — verify it has not been enabled)
Apache: Options -Indexes in .htaccess or VirtualHost config
IIS: Browse disabled in directory browsing settings
Test: attempt to access a directory path without an index file
curl https://[public-site]/[path-without-index]/
Expected: 403 Forbidden or 404 Not Found — NOT a file listing
Error messages — suppress technical detail in production:
ASP.NET: <customErrors mode="On" defaultRedirect="~/Error.aspx" />
<compilation debug="false" /> (never debug=true in production)
Django: DEBUG = False in production settings
PHP: display_errors = Off; log_errors = On in php.ini
Node.js: do not send stack traces in HTTP responses
Test: trigger an error deliberately (e.g. malformed request)
Expected: generic error page — not a stack trace or file path
Robots.txt — do not use to "hide" sensitive paths:
robots.txt is publicly readable — it tells attackers exactly which
paths to target if they are listed as Disallow
Content that should not be public must be access-controlled,
not merely excluded from robots.txt
Public API endpoints — confirm no CUI returned without auth:
For each public API endpoint:
Test unauthenticated: curl https://[api-endpoint]/[path]
Expected: 401 Unauthorized or 403 Forbidden for any endpoint
that could return CUI
Any endpoint returning CUI data without authentication = Critical finding
Cyber Essentials — technical verification procedures
Cyber Essentials Secure Configuration is assessed at two levels: the self-assessment questionnaire (CE standard) and technical verification (CE+). For CE+ the assessor will connect to sample devices and verify settings directly. The following procedures are both the implementation specification and the pre-assessment verification checklist.
Requirement 1 — Only necessary software is installed
Approved software list governance:
Location: AT-CM → Approved Software List (version-controlled Confluence page)
Categories: Productivity / Developer tools / Security tools /
Privileged utilities / Approved browser extensions
Denied software register: maintained alongside approved list
Enforcement mechanisms by platform:
Windows (standard endpoints):
Admin rights removed from all standard user accounts
GPO: Software Restriction Policies or WDAC policy restricting
execution to approved paths
Intune: Win32 app detection rules flag unapproved installations
Windows (servers):
Windows Defender Application Control (WDAC) policy in enforce mode
Application allowlist: signed publisher rules for approved software
Anything unsigned or from an unapproved publisher: blocked
macOS:
Gatekeeper: App Store and identified developers (MDM-enforced)
Jamf: software restriction policies blocking specific application bundles
MDM: restrict App Store to managed account
Linux:
Package manager: apt/yum locked to approved repository list only
Unapproved repositories disabled at build time via Ansible
dpkg/rpm queries logged to SIEM for new package installations
Unapproved software detection:
Intune: Discovered apps report — weekly review by IT Operations
Intune portal → Devices → [device] → Discovered apps
Compare against approved software list
Unapproved app: immediate ITSM ticket; remove within 5 business days
Jamf: Software inventory smart group:
"Applications not in approved list" smart group
Members reviewed weekly
Quarterly EV-D20 spot check:
For 10% sample of CUI-scope Windows devices:
Get-WmiObject Win32_Product | Select-Object Name, Version, Vendor
Compare against approved software list
Any unapproved software: document in audit finding; create ITSM ticket
Browser extension control:
Chrome GPO (Windows):
ExtensionSettings policy:
"*": {"installation_mode": "blocked"}
"[approved-extension-id]": {"installation_mode": "allowed",
"update_url": "[CWS update URL]"}
Verify: launch Chrome on a test device → try to install an extension
not on the approved list
Expected: "This extension is blocked by the administrator"
Safari (macOS via MDM):
Restrictions payload: allowExtensions = false (or managed extension list)
Firefox:
policies.json ExtensionSettings key
managed_policies.json deployed via Intune or Jamf
Requirement 2 — Default passwords changed before deployment
Pre-deployment credential checklist — mandatory before any device
enters production or CUI-scope use:
Network devices (routers, switches, firewalls, APs):
[ ] Default admin web UI password: changed to [PAM-generated complex]
[ ] Default SNMP community string: changed or SNMP v3 with auth/priv configured
[ ] Default SSH credentials: changed; key-based auth configured;
password auth disabled where platform supports
[ ] Default Wi-Fi PSK (if applicable): changed; WPA3-SAE or WPA2-Enterprise configured
[ ] Any default local accounts not needed: disabled or deleted
Verification:
Attempt login with manufacturer-documented default credentials
Expected: authentication failure
If successful: immediate finding — change before connecting to any network
Look up the device model's default credentials:
cirt.net default passwords database
router/switch vendor documentation
These are the credentials attackers will try first
Windows servers and workstations:
[ ] Local Administrator account: password set to [LAPS-generated; LAPS v2 deployed]
[ ] Built-in Administrator account name: optionally renamed (security through obscurity
only — LAPS is the primary control, renaming is supplementary)
[ ] Guest account: disabled
[ ] Default IIS application pool credentials (if IIS installed): changed
[ ] Any application-specific default accounts: documented in asset register;
changed before the application handles any data
LAPS v2 verification:
Get-LapsADPassword -Identity [computer-name] -AsPlainText
Expected: a LAPS-generated password (complex, unique per device)
If blank or default: LAPS not functioning on this device — investigate
Linux servers:
[ ] Root password: either locked (PermitRootLogin no in sshd_config)
or set to PAM-generated complex value in vault
[ ] Default application accounts (e.g. mysql root, postgres superuser):
changed or locked before service handles production data
[ ] Default SSH host keys: regenerated at deployment (not cloned from image)
ssh-keygen -A (regenerates all host key types)
Verify host key is unique: compare fingerprint against any other server —
if identical, image was cloned with host keys still present
[ ] Any vendor-provided default accounts in installed applications:
changed before the application is connected to the network
Applications and SaaS:
[ ] Every application with a default admin credential (content management systems,
monitoring tools, network management platforms, backup consoles):
changed before the application is accessible from any network
[ ] Application vendor documentation searched for known default credentials —
these are what attackers search for first after identifying the product version
Quarterly verification of no default credentials (EV-D20 spot check):
Select 3 network devices, 3 servers, 3 workstations
Attempt login with the manufacturer-documented default credential for each
Expected: all fail — any success is a Critical finding
Document: "Default credential verification — [N] devices tested — all fail"
Requirement 3
##### Requirement 3 — Unnecessary accounts removed or disabledThis requirement overlaps significantly with the access control programme
(FC-03, AT-AC). The Cyber Essentials-specific configuration element is the
built-in and default accounts that exist without any provisioning action —
these are configuration artefacts, not identity management decisions.
Windows — built-in account audit:
For each CUI-scope Windows system, verify:
Get-LocalUser | Select-Object Name, Enabled, LastLogon, Description
Expected state:
Administrator: ENABLED but renamed and LAPS-managed (acceptable)
OR DISABLED if a domain admin account is used instead
Guest: DISABLED — non-negotiable; Guest enabled = CE finding
DefaultAccount: DISABLED
WDAGUtilityAccount: DISABLED (or Enabled only if Windows Defender
Application Guard is in use)
[Any other local accounts not needed for the system's function]: DISABLED
Domain accounts on workstations:
No stale domain accounts with local logon rights beyond what is required
Domain Users group should be the standard local group membership —
no individual domain accounts granted local admin or local logon rights
outside of the standard GPO-applied groups
Linux — account audit:
awk -F: '($7 != "/sbin/nologin" && $7 != "/bin/false" && $7 != "/usr/sbin/nologin")
{print $1, $7}' /etc/passwd
Output: accounts that can log in interactively
Review each: is this account needed? Is its shell appropriate?
Service accounts should have /sbin/nologin as their shell
Lock unused system accounts:
usermod -L [account] (lock — prevents password auth; SSH key auth still possible)
usermod -s /sbin/nologin [account] (additionally prevent interactive shell)
Check for empty passwords:
awk -F: '($2 == "" ) {print $1}' /etc/shadow
Expected: no output — any account with empty password = Critical finding
Application and service accounts — quarterly audit:
For each application in the approved software list that has its own
user account database (not delegating to AD/Entra ID):
Export user list from the application
Cross-reference against HR active employee list
Disabled accounts for departed staff within the application:
Finding if not aligned with EV-D04 (leaver de-provisioning)
Application accounts with no last-login in 90+ days: investigate
DEFSTAN note:
Any account with access to OFFICIAL information that cannot be attributed
to a named individual is a Profile 0 finding — the attribution requirement
applies to application accounts as well as OS accounts
Requirement 4 — Patching and auto-update
The full patching procedure is documented in AT-RA (vulnerability scanning)
and AT-SI (flaw remediation). The Cyber Essentials specific requirements
are the SLA thresholds and the EOL software prohibition.
Cyber Essentials patching SLA (from vendor release date):
High severity or Critical: within 14 days
(Our policy: Critical 7 days / High 14 days — meets and exceeds CE requirement)
Note: Cyber Essentials uses the term "high risk" rather than mapping
to CVSS scores. Assessors typically treat CVSS 7+ as "high risk" for CE purposes.
Our CVSS-based SLA table (EV-D07) satisfies this.
Auto-update configuration:
Windows endpoints (Intune / WSUS):
Windows Update for Business policy:
Quality updates: 0-day deferral (apply immediately on release)
Feature updates: [N]-day deferral (assess before deploying to CUI-scope)
Active hours: configured to minimise disruption
Forced restart: after [N] days if user has not restarted voluntarily
Verify:
Get-WUHistory | Sort-Object Date -Descending | Select-Object -First 20
Confirm: recent updates applied within 14 days of release
macOS (Jamf or Intune):
MDM policy: AutomaticUpdateInstall = True
Critical updates: apply immediately
Verify: System Preferences → Software Update → "Automatically keep Mac up to date"
MDM-enforced — user cannot disable
Applications:
For each application in the approved software list:
Auto-update: enabled where available
Where auto-update is not available: add to manual patch calendar
Patch status: included in monthly EV-D07 patch tracking register
(not just OS patches — application patches are in scope)
Browser (highest-risk application — most phishing leverages browser vulnerabilities):
Chrome: update cadence = "Automatic updates" — no user delay permitted
Edge: automatic updates via Windows Update or Intune
Verify current browser version: policies force update if behind by >1 version
Browser plugins and extensions:
Outdated browser extensions are in scope for Cyber Essentials
Extensions on the approved list: auto-updated via browser update mechanism
Verify: no extension in the approved list has a known CVE in the current version
EOL software prohibition:
No in-scope device runs an operating system or application past vendor support end date
EOL tracking register — part of EV-D22 (asset register):
Field: "Vendor support end date" for each OS and application version
Field: "EOL flag" — populated automatically when current date > support end date
Monthly report: CISO reviews EOL flags; any flagged item creates ITSM ticket
Verify for Cyber Essentials assessment:
Windows: Lifecycle policy at microsoft.com/en-us/windows/lifecycle
macOS: Typically 3 major versions supported — check Apple's support page
Ubuntu: LTS releases supported 5 years; Standard releases 9 months
Application versions: check vendor lifecycle page per application
EOL system on CUI-scope network: CE finding regardless of other compensating controls
Cyber Essentials has no provision for risk acceptance on EOL software in scope
Remediation: upgrade or remove from scope before assessment
Requirement 5 — Firewalls (configuration element)
The firewall configuration requirement from a secure configuration perspective:
every firewall rule must represent a deliberate, documented, reviewed decision.
The full firewall implementation procedure is in FC-01 IT Staff procedures.
The secure configuration-specific verification for Cyber Essentials:
Pre-assessment firewall configuration check:
[ ] Every rule in the active rule base has a non-empty description field
[ ] No rules with source = "any" AND destination = internal AND action = permit
(except the default-deny rule itself, which has action = deny)
[ ] No rules created more than 12 months ago that have had zero traffic hits
[ ] Management interfaces not accessible from the internet (external port scan)
[ ] Default deny is the last rule in each policy and is logging
Default credentials on firewall platform:
This bridges Requirement 2 and Requirement 5
Firewall admin account: not using vendor default (admin/admin, admin/password etc.)
Verify: attempt vendor-documented default credentials
Expected: authentication failure
DEFSTAN Profile 0 firewall documentation requirement:
Firewall rule documentation must be sufficient for a contracting authority
assessor to understand what is permitted and why
Rule names must be descriptive, not "Rule_47" or "New Rule"
Any rule without a clear business-readable name and description:
Rename and document via RFC before assessment
DEFSTAN Profile 0 — configuration baseline documentation requirement
DEFSTAN Profile 0 §Secure Configuration requires a documented baseline
for every class of system handling OFFICIAL information. This section
defines what constitutes acceptable baseline documentation and how it
is produced and maintained.
Baseline documents in scope:
BL-WIN11 (Windows 11 workstations)
BL-WINSRV (Windows Server 2022)
BL-MAC (macOS workstations)
BL-UBUNTU (Ubuntu 22.04 LTS servers)
BL-NET (network devices — firewalls, managed switches)
BL-CLOUD (cloud resources — AWS, Azure, GCP)
Each baseline document must contain:
1. Reference standard: which authority is this based on?
(CIS Benchmark version, NCSC guidance reference, vendor hardening guide)
Without a reference, the baseline is not independently evaluable
2. Scope: which specific systems does this baseline apply to?
By OU (Windows), by MDM configuration profile (macOS), by Ansible inventory group (Linux)
3. Enforcement mechanism: how are these settings applied?
GPO name and OU / MDM profile name / Ansible playbook and role
4. Per-setting documentation:
Setting name | Required value | Reference (CIS control number) | Enforcement method
5. Deviations from the reference standard:
Any setting where we deviate from the CIS Benchmark recommendation
must have a documented justification
Example: CIS recommends disabling Bluetooth; we permit Bluetooth
for approved peripherals — deviation documented with compensating control
(Compensating control: MDM device control prevents Bluetooth data transfer
to unapproved device types; only keyboard/mouse/headset permitted)
6. Version and review date:
The baseline is version-controlled (Confluence page history)
Annual review confirmed by IT Manager signature on the page
DEFSTAN contracting authority access to baseline documentation:
If the contracting authority requests the secure configuration baseline
as part of a DEFSTAN assessment, provide:
The BL-[PLATFORM] Confluence page export for the relevant system type
Do NOT provide: the full SIEM correlation rules, the PAM architecture,
or the full network topology with specific IP ranges
These contain operational security detail beyond what Profile 0 requires
Produce a summary version for the contracting authority if needed
Quarterly configuration audit procedure (generates EV-D20)
The quarterly configuration audit is the primary evidence that secure
configuration is maintained, not just set at deployment. It uses CIS-CAT Pro
to produce an automated benchmark comparison for each platform and supplements
this with manual checks for Cyber Essentials and DEFSTAN-specific requirements.
CIS-CAT Pro scan — execution and scope:
Full procedure: FC-02 IT Staff Technical Procedures → CIS-CAT Pro quarterly scan
Scope for CE and DEFSTAN: all CUI-scope systems (servers = full; workstations = 10% sample minimum)
Benchmark profiles used:
Windows 11: CIS_Windows_11_Benchmark_[current-version]-L1
Windows Srv: CIS_Windows_Server_2022_Benchmark_[current-version]-L1
macOS: CIS_Apple_macOS_[current-version]-L1
Ubuntu: CIS_Ubuntu_Linux_22.04_Benchmark_[current-version]-L1
Additional checks beyond CIS-CAT Pro:
CE-specific checks (run manually or via script, every quarter):
Check 1 — Software inventory vs approved list:
Windows:
Get-WmiObject Win32_Product | Select-Object Name, Version |
Sort-Object Name | Export-Csv "software-[hostname].csv"
Compare against approved software list CSV
macOS:
system_profiler SPApplicationsDataType |
awk '/Application Name:/{print $0}' > apps-[hostname].txt
Compare against approved list
Output: list of unapproved applications per device
Action: each unapproved app → ITSM ticket → remove within 5 days
Check 2 — Default credentials:
For each network device in scope: attempt default credential (automated where possible)
For each Windows server: verify LAPS is generating and rotating credentials
For each Linux server: verify root is locked or password is PAM-vault-managed
Check 3 — EOL software:
Run Microsoft Lifecycle API or manual check for each OS version in asset register
Run version check for each application against vendor lifecycle page
Output: list of EOL systems or applications in scope
Action: each EOL item → escalate to IT Manager → remediation plan within 14 days
Check 4 — Unnecessary user accounts:
Run the account audit commands from Requirement 3 section above
On 3 sample devices of each OS type
Output: list of unexpected accounts
Action: each unexpected account → investigate and disable if not required
Check 5 — Auto-update status:
Windows: Get-WUHistory (last 20 updates) — confirm Critical/High within SLA
macOS: softwareupdate --history (last 20 updates)
Output: date of most recent OS update; confirm within 14 days of release
Action: any device more than 14 days behind Critical update → immediate remediation
Check 6 — Publicly accessible systems (AC.L1-3.1.22):
Review publicly accessible system register
Web crawl each public URL (without authentication) for CUI content
AWS/Azure public access block verification (commands above)
SharePoint external sharing verification
Output: confirmed "no CUI on public systems" or list of findings
DEFSTAN-specific checks (run manually every quarter):
Check DEFSTAN-0-1 — Baseline documentation currency:
For each BL-[PLATFORM] document in Confluence:
Confirm last reviewed date is within 12 months
Confirm version matches the CIS Benchmark version used in CIS-CAT Pro scan
If CIS Benchmark has been updated since last baseline review: create ITSM ticket
Check DEFSTAN-0-2 — Default credentials on all in-scope network devices:
Network device audit: all firewalls, managed switches, APs in OFFICIAL scope
Attempt default credentials for each device type (from cirt.net reference)
Expected: all fail
Any success: Critical finding — change immediately; document in EV-D08
Check DEFSTAN-0-3 — Unnecessary services on OFFICIAL-scope servers:
For each CUI-scope server:
Linux: ss -tlnp | compare against approved services list for this server role
Windows: Get-Service | Where-Object {$_.Status -eq "Running"} |
compare against approved services list
Any running service not in the approved list for this server's role:
Investigate → stop and disable if not needed → RFC if needed but not in baseline
EV-D20 record structure:
EV-D20 Quarterly Configuration Audit — [YYYY-QQ]
Audit scope:
Servers audited: [N of N total CUI-scope servers] (full population)
Workstations audited: [N] of [N total CUI-scope workstations] ([%] sample)
Network devices audited: [N]
CIS-CAT Pro results summary:
| System | OS | CIS Profile | Score | Findings: Critical | High | Medium |
[one row per scanned system]
Cyber Essentials checks:
Check 1 (Software inventory): [N] systems checked — [N] unapproved items found
Items: [list or "None"]
Check 2 (Default credentials): [N] systems/devices checked — all fail / [findings]
Check 3 (EOL software): [N] items checked — [N] EOL found / None
Check 4 (Unnecessary accounts): [N] systems checked — [N] findings / None
Check 5 (Auto-update status): [N] devices checked — all within SLA / [findings]
Check 6 (Public systems review): [N] public systems reviewed — No CUI found / [findings]
DEFSTAN-specific checks:
Check DEFSTAN-0-1 (Baseline currency): All current / [findings]
Check DEFSTAN-0-2 (Network device defaults): All fail default creds / [findings]
Check DEFSTAN-0-3 (Unnecessary services): All services accounted for / [findings]
Findings summary:
CIS-CAT findings requiring remediation: [N Critical, N High, N Medium]
CE-specific findings: [N]
DEFSTAN-specific findings: [N]
All findings: entered in EV-D08 (exception register) within 5 business days
Remediation SLA: Critical 7 days / High 14 days / Medium 30 days / Low 90 days
IT Manager sign-off: _________________ Date: _________
CISO review: _________________ Date: _________
File at: EV-D → Config Management → Config Audits → [YYYY-QQ]
Configuration exception management (generates EV-D08)
When a configuration finding cannot be remediated within the standard SLA:
Exception trigger conditions:
Business dependency: remediation would break a required service
(e.g. patching a setting breaks an application that has no workaround)
Vendor constraint: the vendor has not yet released a fix
Testing gap: fix requires staging environment test and window is not available
Operational constraint: the remediation window conflicts with a critical delivery
Exception record requirements:
EV-D08 entry — per configuration deviation:
Finding reference: [CIS control ID / CE requirement / DEFSTAN check]
System(s) affected: [hostname(s)]
Setting affected: [specific setting and its current vs required value]
CIS-CAT Pro finding: [finding text from scan report]
Reason remediation is delayed: [specific reason from the list above]
Supporting evidence: [ITSM ticket from vendor / testing calendar entry / etc.]
Risk assessment:
Likelihood of exploitation without the setting: [Low / Moderate / High]
Impact if exploited: [Low / Moderate / High]
Overall risk during exception: [Low / Moderate / High]
Compensating controls:
[Describe specifically what is in place to reduce the risk while
the setting is not at the required value]
Examples:
Network isolation: affected system not reachable from internet
or untrusted network segments
Enhanced monitoring: SIEM alert configured to detect exploitation
of this specific configuration gap
Access restriction: only named accounts with strong auth can reach
the affected system
Expected remediation date: [date — within SLA limits]
Critical: maximum 30 days total (7-day standard + max 23-day exception)
High: maximum 30 days total
Medium: maximum 90 days
Low: maximum 12 months (annual risk acceptance decision)
Approval:
High and Critical exceptions: CISO signature required
Medium and Low: IT Manager signature sufficient
Monthly review note: updated by CISO each month until exception is closed
Closure:
Remediation confirmed: [describe verification performed]
Confirmed by: [IT Manager name]
Closed date: [date]
Evidence generation — this control family
| Evidence ID | What to produce | When | How | Filed at |
|---|---|---|---|---|
| EV-D19 | Baseline configuration specifications — BL-[PLATFORM] documents for all six platform types | Annual review + on major OS/CIS release | CIS Benchmark comparison; IT Manager sign-off | AT-CM → Baseline Documents |
| EV-D20 | Quarterly configuration audit — CIS-CAT Pro output, CE checks, DEFSTAN checks, deviation analysis, IT Manager sign-off | Quarterly — Q1/Q2/Q3/Q4 | CIS-CAT Pro + manual checks as defined above | EV-D → Config Management → Config Audits → [YYYY-QQ] |
| EV-D21 | Change management records — RFC for every configuration change to CUI-scope systems | Per change | ITSM RFC with SIA; CAB review; post-change verification | EV-D → Config Management → Change Log |
| EV-D22 | Asset register — includes OS version, application versions, vendor support end dates, EOL flag | Quarterly reconciliation | CMDB/asset tool export + network discovery comparison | EV-D → Config Management → Asset Register |
| EV-D08 | Configuration exception register — per deviation from baseline with compensating control and approval | Per exception raised | CISO or IT Manager sign-off; monthly review note | EV-D → Vulnerability Management → Patch Exceptions |
Evidence production calendar:
Weekly (automated):
[ ] Ansible check-mode drift report — Linux CUI servers
[ ] MDM non-compliance alerts — Windows and macOS (review daily queue)
[ ] SIEM alert: new software installation event on CUI-scope device
Monthly:
[ ] MDM discovered apps report — compare against approved software list
[ ] EOL flag check in asset register — any new items since last month
[ ] Public system check — AWS/Azure public access block status verification
Quarterly:
[ ] EV-D20 — full CIS-CAT Pro audit + CE checks + DEFSTAN checks
[ ] EV-D22 — asset register reconciliation against network discovery
[ ] EV-D08 — exception register review; close resolved items; extend or escalate aging items
Annually:
[ ] EV-D19 — full baseline review for all six BL-[PLATFORM] documents
[ ] CIS Benchmark version check — confirm within one minor version
[ ] Approved software list comprehensive review
Per event:
[ ] EV-D21 — RFC created and fully documented for every configuration change
[ ] EV-D08 — exception record created within 5 business days of any audit finding
{scroll-content}
Security-staff layer
SCM variant: isms-security — visible to isms-security only.
{scroll-content:variant=isms-security}
Evidence currency dashboard
Review and update at the beginning of each month. A red status requires action before any assessment.
| Evidence ID | Item | Required frequency | Last produced | Status | Owner |
|---|---|---|---|---|---|
| EV-D19 | Baseline configuration specifications — all six BL-[PLATFORM] documents | Annual + on major release | [date] | [Current / Overdue] | IT Manager |
| EV-D20 | Quarterly configuration audit (CIS-CAT Pro + CE + DEFSTAN checks) | Quarterly | [date] | [Current / Overdue] | IT Manager |
| EV-D21 | Change management records — all configuration RFCs | Per change | [date of most recent RFC] | [Current / Gap if undocumented change made] | IT Manager |
| EV-D22 | Asset register including OS version and EOL flags | Quarterly reconciliation | [date] | [Current / Overdue] | IT Operations |
| EV-D08 | Configuration exception register — all open deviations | Per exception; monthly review | [date of most recent entry] | [Current / Check if audit findings entered] | CISO |
Critical dependency:
EV-D20 credibility depends on EV-D21 completeness. If configuration changes have been made without RFCs since the last audit, the audit baseline cannot be trusted — changes that were made without documentation may have introduced settings that diverge from the documented baseline without the audit detecting them. Verify EV-D21 is complete for the period before relying on EV-D20 as assessment evidence.
EV-D19 (baseline specifications) is the reference against which EV-D20 (audit results) is evaluated. If EV-D19 was not updated after the most recent CIS Benchmark release, the audit is comparing against a potentially outdated standard. Confirm CIS Benchmark version alignment before any assessment.
MITRE ATT&CK context — what this control family detects and prevents
Secure configuration is primarily a preventive control — it removes the conditions that many attack techniques depend on. The following maps this family's controls to the ATT&CK techniques they prevent or detect.
T1190 — Exploit Public-Facing Application: The AC.L1-3.1.22 control directly prevents CUI exposure via exploited public applications. If CUI is not present on public-facing systems, a successful exploitation of a public web application cannot directly reach CUI. The control also reduces the information available to attackers performing reconnaissance — server headers removed, directory listings disabled, error messages sanitised. SIEM detection: anomalous HTTP response patterns from DMZ systems; IDS alerts for application layer exploitation signatures.
T1592 — Gather Victim Host Information: Default settings and undisclosed software versions are primary reconnaissance targets. An attacker scanning our public presence for server headers, default login pages, and version disclosure in error messages is conducting T1592. Removing server headers, disabling directory listing, and suppressing error details all reduce the reconnaissance value of our public footprint. SIEM detection: high-volume HTTP HEAD requests or OPTIONS requests against public services; automated scanner signatures in IDS/IPS alerts.
T1078.001 — Valid Accounts — Default Accounts: The default credential requirement directly prevents this technique. Default accounts that are left enabled with default passwords are a documented, searchable vulnerability — cirt.net and similar resources list them publicly. An attacker who identifies our firewall model or server OS version can look up the default credentials and attempt them. The quarterly default credential verification (EV-D20 Check 2) is the detective control; the pre-deployment checklist is the preventive control. SIEM detection: authentication success for any account named "admin," "administrator," "root," or matching common default patterns.
T1059 — Command and Scripting Interpreter: Unnecessary software and services create execution opportunities for attackers. An attacker who gains access to a system with PowerShell Transcription disabled, Script Block Logging disabled, and an unrestricted execution policy has a significantly easier time executing malicious scripts than on a hardened system. The BL-WIN11 baseline settings for PowerShell logging (Transcription + Script Block Logging) directly detect this technique. SIEM detection: Windows Event 4104 (Script Block Logging) showing encoded or obfuscated commands; process creation events showing unusual parent-child relationships (Word spawning PowerShell).
T1505.003 — Web Shell: A web shell requires the attacker to upload an executable script to a web server and then access it via the browser. Secure configuration prevents this through: disabling directory listing (prevents browsing for uploaded files); application allow-listing on servers (prevents execution of files not in the approved list); file upload validation in applications (not a baseline control, but documented in AT-SC-ARC); and WDAC on servers preventing unsigned script execution. SIEM detection: IDS alert for web shell access patterns; outbound connections from web server processes; Windows Event 4688 showing unusual processes spawned by IIS worker process.
T1562.001 — Impair Defenses — Disable or Modify Tools: Tamper protection on the EDR platform prevents attackers from disabling endpoint protection. The BL-WIN11 baseline setting "Tamper protection: Enabled" via Intune satisfies this. SIEM detection: Windows event for Defender tamper protection triggered; EDR platform event for protection component disabled; SIEM alert rule "AV protection disabled on CUI-scope device."
Control effectiveness assessment — quarterly
Complete each quarter as part of the internal assessment programme (AT-CA 3.12.1).
| Control | Test | Last tested | Result | Trend | Notes |
|---|---|---|---|---|---|
| No unapproved software on CUI-scope Windows devices | MDM discovered apps report — compare against approved list | [date] | [N unapproved items] | ↑↓→ | Target: 0 |
| No unapproved software on CUI-scope macOS devices | Jamf "Applications not in approved list" smart group count | [date] | [N non-compliant] | ↑↓→ | Target: 0 |
| No default credentials on network devices | Attempt default creds on 3 sample devices | [date] | Pass / Fail | ↑↓→ | |
| No default credentials on servers (LAPS active) | Get-LapsADPassword on 3 sample servers | [date] | Pass / Fail | ↑↓→ | |
| Guest account disabled on all CUI-scope Windows | Get-LocalUser where Name=Guest on 3 sample devices | [date] | Pass / Fail | ↑↓→ | |
| No EOL OS or applications in CUI scope | Asset register EOL flag count | [date] | [N EOL items] | ↑↓→ | Target: 0 |
| Critical patches within 7-day SLA | EV-D07 — Critical findings, vendor release date vs remediation date | [date] | [% compliant] | ↑↓→ | Target: 100% |
| No CUI on publicly accessible systems | Public web crawl + cloud public access block verification | [date] | Pass / Fail | ↑↓→ | |
| Server headers not disclosing version | curl -I on public URLs — no Server/X-Powered-By | [date] | Pass / Fail | ↑↓→ | |
| Directory listing disabled on public web servers | Attempt directory browse on sample paths | [date] | Pass / Fail | ↑↓→ | |
| CIS-CAT Pro score ≥ 80% on all CUI-scope systems | EV-D20 most recent quarterly scores | [date] | [lowest score %] | ↑↓→ | Target: ≥80% all systems |
| Windows Defender tamper protection active | Get-MpComputerStatus — AMTamperProtectionEnabled | [date] | Pass / Fail | ↑↓→ | |
| All baseline document versions current within 1 CIS minor release | BL-[PLATFORM] document version vs current CIS release | [date] | Pass / Fail | ↑↓→ |
Assessor preparation — C3PAO, Cyber Essentials+, and DEFSTAN
C3PAO examination (CMMC Level 1 — AC.L1-3.1.22)
This is the only CMMC Level 1 practice that sits in the secure configuration
domain. The remaining Level 1 practices in this page's scope are Cyber
Essentials and DEFSTAN obligations rather than CMMC L1.
Documents to prepare:
[ ] Publicly accessible system register (in EV-D20) — current quarter's version
Must show: all public systems listed, each reviewed for CUI, review date
[ ] AWS/Azure/GCP public access block verification export (commands above)
[ ] SharePoint external sharing report (PowerShell output)
[ ] Most recent web crawl output for public systems
[ ] Evidence that no CUI-classification content appears in public pages
(screenshot or crawl report showing no CUI headers/markings on public pages)
Technical demonstration:
[ ] Browse the public website without authentication → confirm no CUI visible
[ ] Show a SharePoint site for a DEFSTAN contract → confirm
sharing set to "Only people in your organisation"
[ ] Show AWS S3 Block Public Access settings for the account
[ ] If a contractor portal exists: browse to the portal without authenticating
→ confirm authentication is required before any CUI-adjacent content appears
Interview talking points for IT Manager:
"How do you ensure that CUI doesn't end up on your public website?"
→ Content management process: all public content reviewed before publication;
CUI classification training means staff know not to include it;
Quarterly audit includes manual review of public content;
automated web crawl flags any document with CUI markers
"What cloud storage do you use, and how do you ensure no CUI is in public buckets?"
→ AWS S3 Block Public Access enabled at account level;
Azure storage accounts have public blob access disabled by policy;
Quarterly audit includes cloud public access verification (command output available)
"If someone accidentally published a CUI document to a public SharePoint link,
how would you find out?"
→ SIEM alert on SharePoint permission change to external/anonymous;
DLP policy flags CUI-labelled documents shared externally;
Quarterly external sharing audit (PowerShell report)
Common finding for this practice:
A SharePoint site for an internal project that was given "Anyone with the link"
sharing permission for a single document, then forgotten. The document is CUI.
Prevention: DLP policy + SharePoint information barriers prevent this
at creation time. Quarterly external sharing audit catches any that
slip through. The combination of preventive and detective controls
is what makes the evidence credible.
Cyber Essentials+ technical verification preparation
The CE+ assessor will connect directly to a sample of your devices
and verify configuration settings. The number of devices is specified
in the CE+ scope document. Typically: all OS types in scope, at least
one server per role, and a sample of workstations.
Prepare a staging device of each type for the demonstration:
This is not a device with artificially perfect settings — it is a
production device that you have pre-verified matches the baseline
The assessor should not be connected to devices without prior preparation —
not because settings are changed for the assessment but because you
should know what the assessor will find before they find it
Windows device verification (assessor will run or observe):
[ ] Get-NetFirewallProfile (confirm all three profiles: Enabled = True, DefaultInboundAction = Block)
[ ] Get-LocalUser (confirm Guest disabled; only expected accounts)
[ ] Get-WmiObject Win32_Product (assessor will spot-check against approved list)
[ ] winver or Get-WmiObject Win32_OperatingSystem (confirm OS is not EOL)
[ ] Get-WUHistory (confirm recent Critical updates within 14 days of release)
[ ] Get-MpComputerStatus (confirm tamper protection, real-time protection enabled)
[ ] Get-ADFineGrainedPasswordPolicy FGPP-Standard-Users (confirm 16-char minimum)
macOS device verification (assessor will observe or run):
[ ] System Preferences → Security → Firewall → On
[ ] System Preferences → Software Update → confirm automatic updates
[ ] /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate (Enabled)
[ ] system_profiler SPApplicationsDataType (spot-check against approved list)
[ ] csrutil status (SIP enabled)
[ ] fdesetup status (FileVault On)
Network device verification (assessor may request or observe):
[ ] Attempt default credentials on sample device (expected: fail)
[ ] Show management interface: confirm HTTPS only; confirm SSH only from management VLAN
[ ] Show firewall rule base: confirm description field populated for all active rules
[ ] Show default deny rule at bottom of active policy
Likely CE+ finding patterns to resolve before assessment:
Finding type 1: Guest account enabled on one or more workstations
Resolution: GPO enforces Guest disabled on all domain-joined devices
Verify: gpresult /h confirms GPO is applying to all CUI-scope OUs
Finding type 2: Unapproved application on a workstation
Resolution: MDM discovered apps report reviewed and actioned
Run the report, resolve all unapproved apps, then run it again to confirm clean
Finding type 3: Browser not up to date on a device
Resolution: Chrome update policy via GPO or Intune forces current version
Verify: policy forces update; no device more than 2 minor versions behind
Finding type 4: Default admin password not rotated on a network device
Resolution: complete the default credential check across all network devices
This is the finding CE+ assessors most frequently find on first attempt
DEFSTAN assessment preparation
DEFSTAN Profile 0 §Secure Configuration examination focuses on:
1. Documented baseline exists for OFFICIAL-scope systems
Prepare: BL-[PLATFORM] documents for each system type in OFFICIAL scope
Show: each document has a CIS Benchmark version reference,
enforcement mechanism, and per-setting documentation
Assessor question: "What is the configuration standard for your workstations?"
Answer: CIS Microsoft Windows 11 Benchmark Level 1, version [X.Y.Z],
enforced via GPO [name]; deviations documented in BL-WIN11 Section N
2. Baseline is actually enforced (not just documented)
Prepare: CIS-CAT Pro scan reports from EV-D20 for representative systems
Show: compliance scores (≥80% expected; critical findings remediated)
Assessor may request: live CIS-CAT Pro demonstration on a selected system
Prepare: ability to run CIS-CAT Pro scan in front of assessor within 30 minutes
3. No default credentials on systems handling OFFICIAL information
Prepare: evidence from EV-D20 Check 2 (default credential verification)
Show: result table showing all tested devices, all returning failure on default creds
Assessor may request: demonstrate by attempting default credential on a named device
Prepare: one network device and one server available for live demonstration
4. Unnecessary services are disabled
Prepare: approved services list for each server role (part of EV-D19)
Show: for a CUI-scope server, demonstrate that only approved services are running
Assessor may ask: "Why is [service] running on this server?"
Answer must reference: the server's documented role and the approved service list for that role
5. Configuration is reviewed at defined intervals
Prepare: last 4 quarters of EV-D20 (quarterly configuration audit records)
Show: reviews are conducted; findings are documented and remediated
Assessor will check: are findings from the previous quarter's audit resolved?
If not: each unresolved finding is a DEFSTAN finding in addition to the original
6. CUI is not on public systems without authorisation
For DEFSTAN context: "OFFICIAL information is not accessible from the internet
without authentication"
Prepare: publicly accessible system register from EV-D20
Show: each public system reviewed, no OFFICIAL content accessible unauthenticated
DEFSTAN-specific note on web services:
If the organisation operates a web presence that serves OFFICIAL customers:
The authentication mechanism, its strength, and the network placement of
the authenticated content are all DEFSTAN evidence items
Ensure the architecture diagram showing authenticated vs unauthenticated
zones is ready for the assessor
POA&M templates — most likely deficiencies for this control family
Template: Unapproved software on CUI-scope device
POA&M item: PM-[YYYY]-[NNN]
Controls: CE Secure Configuration Requirement 1 · DEFSTAN Profile 0 §Secure Config
Weakness: [Application name, version] identified on [N] CUI-scope [Windows/macOS]
device(s) during the [quarter] configuration audit (EV-D20).
This application is not on the approved software list and was not
installed through the approved software request process.
Affected devices: [list hostnames]
Discovery source: EV-D20 quarterly configuration audit — [YYYY-QQ]
Risk during deficiency: [Low / Moderate] depending on application type
Low: consumer productivity application with no network listening services
Moderate: application with network-facing components or known CVEs
Compensating controls: EDR monitoring active on affected devices;
device compliance policy flags the device as non-compliant
and restricts access to sensitive resources
Corrective action: (1) Remove [application] from all affected devices via
MDM/Intune uninstall policy within 5 business days
(2) Investigate how installation occurred — if admin rights
were used by a non-IT account, escalate as a separate
finding (access control breach)
(3) Add [application] to the denied software register with
"not approved — not submitted through proper process" reason
(4) MDM compliance policy will automatically flag re-installation
Owner: IT Operations
Target completion: 5 business days
CISO approval: IT Manager sufficient for Low; CISO required for Moderate
Template: EOL operating system on CUI-scope device
POA&M item: PM-[YYYY]-[NNN]
Controls: CE Secure Configuration Requirement 4 · DEFSTAN Profile 0 §Secure Config
Weakness: [N] CUI-scope device(s) running [OS name and version] which reached
vendor end of support on [date]. No further security patches are
being released by [vendor] for this OS version. The device(s)
will not receive remediation for any newly disclosed vulnerabilities
regardless of severity.
Affected devices: [hostnames]
Discovery source: EV-D22 asset register EOL flag review / EV-D20 quarterly audit
Risk during deficiency: High — EOL OS cannot be patched; any new vulnerability
is permanently unremediable on this device
Compensating controls: Device isolated to a VLAN segment with minimal CUI access;
enhanced SIEM monitoring for anomalous behaviour;
EDR tamper protection active
NOTE: Cyber Essentials has no provision for risk
acceptance on EOL software — the device must be
removed from CE scope or upgraded. These compensating
controls do not satisfy CE+ for an in-scope device.
Corrective action: (1) Upgrade all affected devices to [replacement OS version]
within [planned upgrade date]
(2) If upgrade is not feasible within 30 days: remove
affected device(s) from CUI-scope network pending upgrade
(3) Remove from Cyber Essentials scope declaration until
upgrade is complete (notify CISO and Cyber Essentials
assessor if assessment is pending)
Owner: IT Manager
Target completion: [upgrade date — must be within 30 days for High risk]
CISO approval: required — High risk
Template: CUI found on publicly accessible system
POA&M item: PM-[YYYY]-[NNN]
Controls: AC.L1-3.1.22 (CMMC Level 1) · DEFSTAN Profile 0 §Secure Config
Weakness: [Document/page/file name and URL] identified on [public system URL]
as accessible without authentication. The document contains
[CUI category — describe briefly without reproducing CUI content].
Discovery date: [date]. Estimated exposure period: [date first published]
to [date removed].
Discovery source: [Quarterly public system review / External report / Internal report]
Risk during deficiency: HIGH — CUI has been publicly accessible
This is a reportable incident:
DFARS §252.204-7012: 72-hour reporting to US DoD DIBNet portal
from discovery date — CISO to assess within 4 hours of this POA&M entry
DEFSTAN contract: 24-hour notification to contracting authority
UK GDPR: DPO to assess whether personal data is involved
Incident record: create in EV-D12 immediately
Compensating controls: CUI removed from public access: [date and time]
Corrective action: (1) Verify complete removal of CUI from public system
(confirm not cached, not in search engine cache,
not in Wayback Machine — request removal if cached)
(2) Complete DFARS reporting if within 72 hours of discovery
(3) Complete DEFSTAN contracting authority notification
within 24 hours of discovery
(4) Post-incident review: how was CUI published publicly?
DLP gap? Process failure? Training gap?
(5) Corrective action to prevent recurrence:
DLP policy update / SharePoint permission review /
publication approval process change
Owner: CISO (incident commander) + IT Manager
Target completion: CUI removed immediately; reports filed within mandatory windows;
corrective action within 14 days
CISO approval: this IS the CISO — Senior management notification required
Template: Default credentials found on deployed network device
POA&M item: PM-[YYYY]-[NNN]
Controls: CE Secure Configuration Requirement 2 · DEFSTAN Profile 0 §Secure Config
Weakness: Default administrative credentials for [device model] confirmed
functional on [device hostname/IP] during [quarter] configuration
audit EV-D20 Check 2. The device is in [Zone/network segment]
and handles [describe: routing for CUI VLAN / firewall for DMZ / etc.].
Default credential: [do not document here — reference cirt.net and
the audit record; the credential itself should not be in a document
that persists]
Discovery source: EV-D20 quarterly configuration audit — [YYYY-QQ]
Risk during deficiency: Critical — any device on a network accessible to this
segment can authenticate as admin to this device
using publicly documented credentials
Compensating controls: Device management interface accessible only from Zone 4
management VLAN (not from general office or internet) —
reduces exposure but does not eliminate the risk
Enhanced SIEM monitoring: alert on admin logins to this device
Corrective action: (1) Immediately (within 2 hours) change default credentials
to PAM-generated complex credentials
(2) Verify PAM account created for this device and
credentials stored in the appropriate PAM vault safe
(3) Confirm previous admin sessions using default credential
are terminated (if device shows session list)
(4) SIEM review: check authentication log for this device
in the past 90 days for any admin logins that are not
from known IT Operations IP addresses
(5) Emergency change RFC: filed within 24 hours (immediate
change justified by Critical risk)
Owner: IT Operations (immediate) + IT Manager (verification)
Target completion: credential change within 2 hours; all other steps within 24 hours
CISO approval: verbal obtained — formal within 24 hours per emergency change procedure
Cross-family evidence dependencies — this control family
AT-RA (Risk Assessment): EV-D06 (vulnerability scan reports) and EV-D07 (patch tracking register) from AT-RA are upstream of the patch compliance element of Cyber Essentials Requirement 4. EV-D20 references the patch status of scanned systems — if EV-D06 shows Critical vulnerabilities that EV-D07 shows as unpatched beyond the SLA, this is both an AT-RA finding and a Cyber Essentials finding. Resolve patches before the quarterly configuration audit to prevent dual-family findings.
AT-AC (Access Control): The unnecessary accounts check (CE Requirement 3) uses the same account audit procedure as the quarterly privileged account review (EV-D01). A stale account found in EV-D20 (configuration audit) that should have been removed via the leaver process (EV-D04) is simultaneously a CE Requirement 3 finding and an AT-AC 3.1.1 finding. The leaver process (FC-03, AT-PS) is the upstream preventive control; EV-D20 is the detective control.
AT-SI (System and Information Integrity): The approved software list and auto-update requirements directly connect to AT-SI 3.14.1 (identify and correct flaws) and 3.14.2 (malware protection). An EOL application that cannot receive patches is an unresolvable 3.14.1 finding. Unapproved software may bypass the AV/EDR policy, creating a 3.14.2 gap. EV-D22 (asset register with EOL flags) and EV-D20 (software audit) are shared evidence across this family and AT-SI.
AT-CM (Configuration Management): EV-D19 (baseline specifications) and EV-D20 (configuration audit) are the primary AT-CM evidence items and simultaneously the Cyber Essentials and DEFSTAN secure configuration evidence. The BL-[PLATFORM] documents that AT-CM requires for 3.4.1 and 3.4.2 are the same documents that DEFSTAN Profile 0 requires. Maintaining them for AT-CM automatically satisfies the DEFSTAN documentation requirement.
{scroll-content}
Page footer
All-staff visible — outside all SCM variant wrappers.
Where to go next
| If you are... | Go to... |
|---|---|
| An all-staff user who wants to request a software installation | IT Operations helpdesk — [helpdesk URL] — include: software name, version, source, and business reason |
| An all-staff user unsure whether a file should be on a public-facing system | 04 · User Guidance Hub → Sharing Data and Documents · or contact the CISO |
| An IT Operations engineer implementing the full CM configuration baseline | FC-02 IT Staff Technical Procedures · AT-CM → BL-[PLATFORM] baseline documents |
| An IT Operations engineer running the quarterly configuration audit | FC-02 IT Staff Technical Procedures → CIS-CAT Pro quarterly scan procedure |
| An IT Operations engineer managing the publicly accessible system register | AT-CM → Approved Software List + EV-D20 public system section |
| A security team member preparing for Cyber Essentials+ | This page security layer above + FC-01 security layer (firewall domain) |
| A security team member preparing for a CMMC Level 1 scope review | AT-CA → Section 8 (assessor preparation) + this page security layer |
| A security team member investigating a possible CUI exposure on a public system | Raise incident via AT-IR — EV-D12 immediately; CISO notification within 1 hour |
Version and review
| Version | Date | Change summary | Author | Approver |
|---|---|---|---|---|
| 1.0 | [DATE] | Initial publication | [NAME] | [CISO NAME] |
Page owner: IT Manager · Review: Annual · Questions: [helpdesk URL] or [ciso@organisation.com]