Secure build reviews: verify how systems are configured
A build review examines whether the configuration of a system or service supports its intended security requirements. It can cover operating systems, cloud services, databases, network devices, endpoints or application platforms. The result should show observed settings, the relevant baseline and practical corrective actions.
A secure design can be weakened by default accounts, unnecessary services, excessive privileges or missing logs. A review makes those configuration decisions visible and repeatable.
Reviewed: 26 October 2026.
Build review, vulnerability scan or penetration test?
| Activity | Focus | Useful evidence |
|---|---|---|
| Build / configuration review | Settings, privileges, services, logging and platform controls. | Configuration exports, policies and observed effective settings. |
| Vulnerability scan | Detectable weaknesses and missing fixes. | Validated results linked to assets and versions. |
| Penetration test | Whether weaknesses can be exploited in the agreed scope. | Reproducible attack paths and impact evidence. |
| Architecture review | Trust boundaries, dependencies and design decisions. | Diagrams, data flows and control responsibilities. |
These activities overlap but do not replace one another. A configuration may match a baseline while a business-logic flaw remains in the application.
Choose a technical baseline and record its version
Use a baseline suited to the exact technology, version and role. CIS Benchmarks provide technology-specific configuration recommendations. Vendor hardening guidance and applicable organisational requirements can also inform the review. Record the selected benchmark version, profile and tailoring decisions.
NIST CSF 2.0 is an outcome-based governance framework with six functions—Govern, Identify, Protect, Detect, Respond and Recover. It can help explain why configuration management matters, but it is not a list of operating-system settings. NIST CSF guidance.
Do not apply every setting mechanically. Assess compatibility, operational needs and safety; document justified deviations and safeguards rather than treating a percentage pass score as the whole result.
What to inspect
| Area | Review question | Evidence |
|---|---|---|
| Accounts and privileges | Are default, shared, obsolete or over-privileged accounts present? | Local and central account/role configuration and access records. |
| Services and exposure | Are unnecessary interfaces, ports or management routes enabled? | Service inventory, network rules and effective access checks. |
| Software and updates | Is the platform supported and appropriately updated? | Version/support information and installation verification. |
| Authentication and secrets | Are credentials, certificates and privileged access protected? | Relevant policies, storage, rotation and recovery arrangements. |
| Logging and monitoring | Do useful events reach the intended destination? | Event configuration, sample records, time synchronisation and alert tests. |
| Data and recovery | Are permissions, encryption and recovery settings appropriate? | Access checks, key ownership and restoration evidence. |
What different platform reviews should examine
| Platform or function | Detailed questions | Useful evidence |
|---|---|---|
| Operating systems | Which accounts have local privilege? Are unnecessary services running? Are permissions, remote administration and update settings appropriate? | Effective settings, account/group membership, service inventory and update status for the actual system. |
| Networks and cloud boundaries | Which management and application paths are permitted? Are guest/user, administrative and sensitive service paths separated as intended? | Rules, routes, identities and an agreed reachability check across the relevant boundary. |
| Applications and supporting services | Are defaults, debug features, service identities, secrets, storage permissions and transport settings appropriate? | Runtime configuration and the deployed version, not just a development template. |
| Endpoints | Are protection agents active, updates succeeding and disk/data safeguards applied where required? Can users bypass intended restrictions? | Management reports checked against a sample device, with documented exclusions and failures. |
| Logging and monitoring | Are relevant events captured, timestamps usable and forwarding reliable? Who investigates a failed feed or high-priority event? | A benign test event traced from source to alert/review, plus evidence of access and retention controls. |
Select the applicable CIS Benchmark or vendor guidance for the exact version and role. For cloud services, distinguish organisation/account-level policy from workload settings. For containers or automated deployments, inspect both the image/template and the resulting runtime environment.
A benchmark score can conceal important exceptions. Record the requirement, observed value, reason it matters and whether the recommendation fits the service. Never apply a hardening change blindly to a production system: test compatibility and recovery with its owner.
Review safely and make the evidence reproducible
- Agree systems, versions, purpose, access and evidence handling.
- Collect configuration using authorised, preferably read-only access or validated exports.
- Compare effective settings with the selected baseline and investigate ambiguous results.
- Validate automated findings manually where context or collection limitations matter.
- Prioritise findings by exposure and business impact; agree safe changes and rollback.
- Retest corrected settings and establish a way to detect drift.
Worked finding: an exposed management interface
Observed: a server’s management interface is reachable from a broad user network, although the agreed design restricts administration to a management segment. The report records the affected asset, observed rule and a safe connectivity check.
Impact: a compromised ordinary workstation has an unnecessary route to a sensitive interface. A vulnerability or stolen administrative credential could make this more consequential.
Remediation: restrict the route to authorised administration sources, verify required support access and monitor relevant access attempts.
Acceptance: an ordinary user-network test can no longer reach the interface, authorised administration still works and the effective rule is recorded. If an exception is necessary, document its owner, safeguards and review date.
What to expect in the report
- Scope, asset/version inventory, baseline version and profile, sample rationale and limitations.
- Observed configuration and evidence for each finding, rather than an unexplained pass/fail export.
- Prioritised corrective actions with likely operational considerations and owners.
- Documented exceptions, alternative safeguards and residual risk.
- Retest results and recommendations for monitoring future configuration drift.
For large estates, sample distinct builds and roles deliberately, then validate whether the finding is systemic. Do not describe a small sample as proof that every device has the same configuration.
Keep the baseline effective after the review
A representative sample should cover meaningful variants: system roles, versions, locations, management methods and exceptions. Explain what was not sampled and why. Reconcile centrally reported settings with what is actually effective on the selected devices; an intended policy may be overridden, missing or not applied.
After agreeing corrections, change the reusable build or configuration source as well as the existing affected systems. Otherwise the next deployment may recreate the weakness. Verify the change on a new build and on remediated instances, then monitor for drift from the approved baseline.
Integrate checks into provisioning and significant changes where practical. Automated checks provide consistency, but require current rules, access and interpretation. Keep a human decision for exclusions or findings that depend on business purpose. Track whether recurring failures come from the template, deployment mechanism, local overrides or unclear ownership.
For a constrained legacy device, preserve the support and operational context. Document restricted access, monitoring and a replacement plan where appropriate; do not report an unimplemented benchmark item as fixed merely because the risk has been accepted.
Common questions
Can the review be read-only?
Much evidence can be collected read-only, but some validation may require agreed checks. Define permissions, collection tools and operational limits before starting.
Does passing a benchmark mean the system is secure?
No. It provides evidence about selected settings. Design, vulnerabilities, access practices, applications and operational response still matter.
When should a build be reviewed?
Before broad deployment, after significant platform or role changes and when drift or incidents create concern. Use a maintained baseline in routine build and change processes.
Related guidance
Penetration testing · Security code review · Cyber Essentials controls
Need Help?
If you have any questions about cyber security or would like a free consultation, don't hesitate to give us a call!
For More Information Please Contact Us
ACCREDITATIONS
