Build and configuration review
Build and configuration review
Understand whether an agreed build or platform is configured as intended, where effective settings differ from the expected baseline and which changes would make the greatest security difference.
A penetration tester replies within one working hour with the questions that scope the review.
Overview
What is a build and configuration review?
A build and configuration review compares the effective security settings of an agreed system or platform with the baseline, policy or recognised guidance that should apply. We investigate meaningful exceptions, explain their practical consequence and provide clear, prioritised hardening actions.
This is for you if…
New systems are about to go live
Servers, laptops or a cloud tenant are ready to deploy and you want them checked first.
Nobody has checked the settings
Systems were set up quickly, or by several hands, and have not been reviewed since.
Someone has asked for evidence
An insurer, an auditor or a client wants to see that your systems are hardened.
New to the term? Penetration testing, defined in our glossary
Why you need it
Why does your organisation need a configuration review?
A review can cover a server or endpoint build, a network or security appliance, management infrastructure, a cloud platform or another agreed technology. These are separate scopes, not an assumption that every review includes every category. We agree the relevant baseline and evidence first.
Expected configuration
The baseline, policy, design decision or recognised guidance that should apply to the system.
Effective configuration
The settings and controls that are actually active on the representative build, device or platform.
Exceptions and conflicts
Differences, inherited settings and operational requirements that change the intended security position.
Practical consequence
What the effective configuration could expose and which change should be prioritised.
Motive
Where does configuration risk come from?
Configuration can drift from the approved build as systems change, policies are inherited and operational exceptions accumulate. A benchmark may show that a setting differs from guidance, but it does not by itself explain whether the difference creates meaningful risk in your environment.
We assess the effective setting in context. The report identifies the evidence, the reason it matters, the practical consequence and the change required, so teams can distinguish material exposure from lower-priority hardening work.
Intended baseline
The build standard, policy or security objective the system is expected to meet.
Active setting
The value, rule or control currently applied to the system in scope.
Relevant exception
The operational need, inherited policy or conflict that explains the difference.
Security consequence
The access or exposure the effective configuration could create.
Reach
What can the effective configuration expose?
Recognised benchmarks and vendor guidance provide a useful reference, but context determines the risk. We compare the effective configuration with the agreed baseline, investigate exceptions and, where authorised, safely validate whether a material setting creates the exposure it appears to.
Entry
Define the baseline
The approved build, policy or recognised guidance establishes what should apply.
Yields an expected configuration
Step
Review effective settings
Evidence from the system shows the controls and values that are actually active.
Yields the current configuration
Step
Investigate exceptions
Inheritance, operational needs and conflicts explain material differences.
Yields the relevant context
Impact
Assess the consequence
The finding records the exposure created and the specific change required.
Yields a prioritised action
In practice
Evidence may come from read-only access, configuration exports, management consoles, policy objects or a representative build. The exact method is chosen for the technology in scope and the assurance question you need to answer.
The review does not treat benchmark alignment as the outcome. Each material finding explains what is active, where it applies, how it affects security and what should change. Deeper technical validation is only performed where it is agreed and safe to do so.
Methodology
How Adversify runs a build and configuration review
We agree the platform, baseline, evidence and question, examine active settings, assess exceptions and report priorities. We set review bounds and evidence for each technology before work starts, so all four phases have a clear purpose and an agreed result.
- Configuration
- Servers
- Endpoints
- Network devices
- Cloud services
Engagement design
We agree the platform, representative builds or devices, the baseline or policy that should apply and the questions the review must answer. We also define access, evidence sources and any validation boundaries.
- Platform
- Baseline
- Evidence
Review the configuration
We compare the intended and effective configuration, examining relevant accounts, services, policies, access controls, management settings, logging and other controls for the agreed technology.
- Effective settings
- Policies
- Controls
Evaluate practical exposure
We investigate exceptions and assess what each material difference means in context. Where agreed, we safely validate whether a setting creates the access or exposure indicated by the review evidence.
- Exceptions
- Context
- Safe validation
Reporting and evaluation
Each finding records the setting, evidence, affected scope, practical consequence and recommended change. We prioritise the hardening work, identify where deeper testing may be useful and talk the results through with the responsible teams.
- Evidence
- Hardening priorities
- Debrief
Coverage
What does a build and configuration review cover?
The categories below are examples of separately scoped reviews. An engagement may cover one platform, a representative build or a defined group of devices. Scoping confirms the technology, baseline, evidence and depth required, together with any operational constraints and the questions the final report must answer.
Server builds
Operating system, services, accounts, privilege, remote management, logging and other agreed controls.
Endpoint builds
Representative desktop or laptop builds, including hardening, encryption, local access and security controls.
Firewalls and appliances
Rules, management access, services, authentication, logging and device-specific security settings.
Network and management platforms
Segmentation, administrative boundaries and the systems used to manage connected infrastructure.
Cloud platforms
An agreed cloud environment, its identities, policies, network controls, logging and platform configuration.
Other agreed technologies
A defined application, database, container platform or security product with an accessible configuration.
Each setting is then weighed by its system's role and place in your estate.
What you get
What you get from a build and configuration review
You receive a concise summary for decision-makers and detailed findings for the teams responsible for remediation. Each material finding records the effective setting, evidence, affected scope, practical consequence and prioritised hardening action. We then explain the result to the people responsible for the platform.
You receive
The configuration review report
A short summary for the people who decide, and every finding in full for those who will change the settings.
Evidence for every finding
The setting found, where it was found and why it matters, system by system.
Hardening guidance
The changes to make, in priority order, fitted to each system's role and place in your network.
A debrief with the reviewers
Time with the people who did the work, to recap what was learnt and answer questions.
What changes
- Scope is defined by the agreed technology, representative systems and assurance question
- Benchmark differences are assessed in context rather than reported without qualification
- Each recommendation identifies the setting to change, why it matters and its priority
Questions
Build and configuration review questions
Clients ask how this review differs from penetration testing, which technologies we can assess, how benchmarks are used and what evidence or access is required. We also agree whether a representative build or live system best answers the assurance question.
Not answered here? Ask it on the scoping call
How is a configuration review different from a penetration test?
A penetration test actively probes systems and, where authorised, exploits weaknesses to show how far an attacker could get. A configuration review examines how each system is set up, setting by setting, and can identify weaknesses a test may not reach. It does not replace penetration testing, and many organisations use both.
Which systems and platforms can you review?
We can review agreed server and endpoint builds, firewalls and other appliances, network and management platforms, cloud environments and other technologies where their configuration can be evidenced. These are separately scoped according to the platform and assurance required.
Do you use CIS Benchmarks and vendor guidance?
Yes, where the relevant guidance applies. We can also assess against your own build standard or security policy. A benchmark provides a reference point, but findings are prioritised using the role of the system, the surrounding controls and the practical exposure.
What access and evidence do you need?
This may be read-only access, a configuration export, policy objects, management console access or a representative build. We agree the least intrusive method that provides reliable evidence for the technology in scope.
Can you review a representative build or live firewall?
Yes. A representative build can provide assurance before wider rollout, while a live device may be appropriate when its effective rules and inherited settings matter. We agree the evidence method and safeguards during scoping.
What happens next?
Ask for a review scoped to your systems
Tell us which platform, build or device you want reviewed and the assurance question you need answered. A penetration tester will reply within one working hour to agree the scope, baseline, evidence and deliverables before we quote.
- Scope agreed with you before we start
- CREST-accredited for penetration testing
- York based, UK wide
A penetration tester will help you identify which platform, system or representative build should be reviewed first.