Cybersecurity Audits
Evidence, not assumptions.
An audit is not an opinion about your security. It is a structured comparison between what a recognised baseline requires and what your systems actually do — written down so that anyone can check the same thing again next year and get a comparable answer.
The problem
Most security reports cannot be checked.
They describe impressions, grade them with colours, and leave the reader unable to tell whether anything improved six months later. The finding says „insufficient access control“ and the reader has no way to reproduce, dispute or close it.
Every finding we write has three things attached: what was examined, what the baseline requires, and how to verify the fix. If we cannot supply all three, it is an observation and we label it as one.
Audit is not assessment. An audit compares your systems against a standard, largely with access and documentation. A security assessment tries to break in. They answer different questions and are often commissioned together.
Scope
What gets examined.
Selected with you at the start, based on what the audit is meant to support — a customer requirement, a certification, a board question, or a merger.
- ArchitectureTrust boundaries, data flows, authentication paths and where a single failure would cascade.
- CodeReview of the security-relevant paths: authentication, authorisation, input handling, secrets, dependencies.
- ConfigurationCloud accounts, identity providers, network rules, storage exposure, logging coverage.
- ProcessAccess lifecycle, change management, patch cadence, backup restoration, incident handling.
- Third partiesWhich suppliers hold your data or your access, and what has actually been agreed with them.
- Evidence qualityWhether the controls you rely on produce records that would survive being questioned.
Baselines
Measured against a published standard.
We audit against the baseline that fits your obligation, not against a private checklist. Which one applies is part of the first conversation.
ISO/IEC 27001
Where an information-security management system exists or is being prepared for certification.
CIS Benchmarks
Concrete, testable configuration baselines for operating systems, cloud platforms and services.
NIST CSF / SP 800-53
Common where US federal or enterprise supply-chain requirements are in play.
OWASP ASVS
Application-level verification requirements, used when the subject is software rather than infrastructure.
We audit, we do not certify. An accredited certification body issues the certificate. Our work is the preparation, the gap analysis and the evidence — and, where you want it, a second pass after remediation.
Sequence
How an audit runs.
Define
Systems in scope, baseline, access required, people to interview, and what the report has to be usable for.
Examine
Documentation, configuration exports, code access and interviews. Findings are collected with their evidence attached.
Validate
Draft findings go to your team before the report is final. Anything we misread gets corrected rather than published.
Report and re-check
Prioritised report with remediation paths, plus an optional second pass that confirms which findings are actually closed.
Deliverables
What is on the table at the end.
Findings register
Each entry with scope, evidence, baseline reference, risk rating and a verification step.
Remediation plan
Ordered by risk against effort, so the first week of work is the week that matters most.
Management summary
Two pages a non-technical board can act on, without softening what the register says.
Need an answer you can show someone?
Tell us who is asking — a customer, an insurer, a regulator or your own board. The audience determines the baseline, and the baseline determines the work.