Service 02
Security
audits
A structured, evidence-based review of your security posture — controls, architecture, configuration and policy — ending in a roadmap ordered by risk rather than by alphabet.
In short
A security audit assesses how well your controls, architecture and processes protect the organisation, measured against a recognised framework and against how the systems are actually configured. Where a penetration test asks "can this specific system be broken into?", an audit asks "is this organisation's security managed well enough that it should not have been possible?"
What an audit typically covers
The exact scope is agreed with you, but a full posture assessment typically spans six areas.
Governance and policy
Whether documented policy exists, whether it reflects what the organisation actually does, and whether responsibility for security decisions is assigned to someone real. Policy that nobody follows is worse than no policy, because it creates a false record of control.
Identity and access
Joiner–mover–leaver processes, privileged account handling, multi-factor authentication coverage, service account sprawl, and whether access reviews happen or merely appear in a calendar. Access accumulation is the single most common finding in this area — people gain permissions and never lose them.
Architecture and network
Segmentation, trust boundaries, exposure of management interfaces, remote access, and whether the design assumes a perimeter that no longer exists. We assess against zero-trust principles, described in detail in our application security architecture guide.
Configuration and hardening
Endpoints, servers, cloud tenants and key SaaS platforms reviewed against CIS Benchmarks and vendor baselines — including the settings that were correct at deployment and drifted since.
Data protection
What personal and sensitive data you hold, where it lives, who can reach it, how long it is kept, and whether encryption at rest and in transit is applied where it is claimed to be. This work also feeds directly into GDPR accountability obligations.
Detection, response and resilience
Whether you are logging the things an investigation would need, whether anyone would notice an alert, whether backups are tested rather than merely scheduled, and whether recovery has ever been rehearsed. Untested backups are the finding that turns a bad incident into an existential one.
Frameworks we audit against
We map findings to whichever framework is most useful to you — commonly ISO/IEC 27001:2022 Annex A, the NIST Cybersecurity Framework, CIS Critical Security Controls, or the UK Cyber Essentials scheme for organisations at an earlier stage. Using an established framework matters for a practical reason: it gives findings a shared vocabulary, makes progress measurable between audits, and produces evidence that maps onto what customers and certification bodies later ask for.
How the work runs
Audits combine document review, structured interviews with the people who operate the systems, and hands-on inspection of live configuration. The third part is what separates a useful audit from a paperwork exercise: we look at the actual state of the systems, not only at what the documentation claims about them. Where the two disagree, that gap is itself a finding.
What you receive
A typical audit delivers the following. Depth and emphasis follow the framework chosen and the areas where your risk actually sits, agreed with you before work starts.
- A posture assessment scored against the chosen framework, showing where you stand control by control.
- A gap analysis reporting each control as evidenced, described but not evidenced, or not identified at all in the supplied material — three different problems with three different fixes.
- A prioritised roadmap with effort estimates, sequenced so that dependencies come first and quick wins are not buried behind year-long projects.
- A board-level summary written for people who need to authorise spending, not to read control identifiers.
- Evidence mapping if certification is the goal, so the audit doubles as the first stage of a compliance programme.
Audit, or test, or both?
If you do not have a clear picture of your overall exposure, start with an audit — it maps the estate so that later testing effort goes where it matters. If you already know which system carries the risk and need to know whether it can be broken, start with a penetration test. Organisations that do both usually audit first, remediate, then test to verify that the improvements hold under pressure.
Configuration and build review against DISA STIG and CIS Benchmarks
A configuration review measures a system's actual state against a published hardening baseline — DISA STIG for hypervisors and virtual machines, CIS Benchmarks for cloud platforms, operating systems and endpoint builds — and reports each deviation with its severity classification and the remediation the baseline prescribes. It is the fastest way to find the gap between the build standard you wrote and the build you are running.
ISO/IEC 27001:2022 and NIST CSF 2.0 gap assessment
We assess your control environment against ISO/IEC 27001:2022 and NIST CSF 2.0 as a benchmarking exercise. This is a gap assessment, not a certification audit, and it does not guarantee compliance; it tells you where you stand and what would need to change before an external audit.
Three answers, not two
Every control is reported as one of three states: evidenced, described but not evidenced, or not identified at all in the supplied material. The middle category is where most audit surprises live, and most audits do not report it.
Questions we are asked
What is the difference between a security audit and a penetration test?
A penetration test is depth-first: it takes a defined system and tries to break into it, producing proof of specific exploitable weaknesses. A security audit is breadth-first: it examines controls, processes and configuration across the organisation and measures them against a framework. A test tells you that a door is unlocked. An audit tells you why nobody in the organisation noticed, and what else is likely to be unlocked for the same reason.
Is a security audit the same as a compliance audit?
No. A compliance audit checks conformity against a specific standard's requirements and is often carried out by an accredited certification body with a formal outcome. A security audit of the kind we perform is advisory: it assesses whether your security is effective, using a framework as a yardstick, without conferring or withholding a certificate. The two complement each other — our audits are frequently used to prepare for a formal certification audit, which is covered under compliance consulting.
How often should we audit?
Annually is the common cadence, with an additional review after material change — a significant acquisition, a cloud migration, a new regulatory obligation, or a serious incident. Organisations running a certified management system will also have their own internal audit programme running on a defined schedule, which the standard requires independently of anything we do.
How disruptive is an audit to our team?
The main demand on your side is people's time: typically a series of interviews of an hour or so with the owners of each area, plus gathering documentation and read-only access for configuration review. We work from what already exists rather than asking you to produce new documents for our benefit — if a policy does not exist, that is a finding, not a homework assignment.
What if the audit finds something serious?
Anything that represents an immediate, active risk is raised with your named contact as soon as we find it, not held back for the report. If we find evidence suggesting a compromise has already occurred, we say so immediately and switch to incident response with your agreement — continuing a routine audit around an active intrusion helps nobody.
Next step
Talk to a security consultant
Tell us what you are building, defending or certifying. We will tell you plainly what we would test first, what it takes, and whether you need us at all.