One report, covering policy, configuration and control gaps
Security Audits
A security audit answers a broader question than a penetration test, and a narrower one than a certification programme. It asks where the company actually stands today, across policy and configuration together, in one honest report. It does not attempt to exploit anything, and it does not run as a standing advisory relationship. It exists for the moment a leadership team, an investor or a board needs the whole picture ranked by what matters most.
How a security audit builds a single ranked report
Policy review, configuration review and a risk ranking a board can actually read.
90 secSample frame · video pending01Before setting the audit's width
Technical-only or technical plus process review?
Some audits only need to check configuration. Others need to weigh policy against practice too. Four questions settle how wide this one should run.
Who reads the final report?
A report going to an investor or board usually needs process coverage, since technical detail alone rarely answers their actual question.
Does written policy already exist to review?
A technical-only review fits when no policy exists yet to compare against. Process review needs documentation on the table first.
Is a specific standard already named?
A named standard like SOC 2 pulls in process review by definition, since most frameworks weigh policy as heavily as configuration.
How much time does the audit actually have?
A tight deadline favours a technical-only scope. Process review adds real time for document review and stakeholder interviews.
| Technical-only | Technical + process | |
|---|---|---|
| Reviews | Configuration and systems | Configuration, systems and policy |
| Typical audience | Internal engineering leadership | Board, investor or external party |
| Timeline | Shorter | Longer, includes interviews |
| Best fit | Fast technical baseline | Due diligence or standard-aligned diagnostic |
02Agreed before the review starts
The ledger that keeps a one-report audit honest
Audits drift when a diagnostic quietly turns into an open-ended advisory relationship nobody budgeted for. This keeps the scope from creeping: what you grant access to, what gets reviewed, what comes back as the report, and which decisions the findings still leave to you.
- Your side
You bring
- Read access across the systems the transaction covers
- Any prior audit, assessment or incident history
- The timeline the transaction itself is running against
- Our side
We build
- A technical and process review across the named systems
- A control-gap assessment against a standard the counterparty expects
- Findings ranked by risk in language a non-technical party can read
- Your side
You receive
- A single comprehensive report suitable for the counterparty
- A risk ranking clear enough to inform deal terms
- A remediation estimate for anything materially significant
Never leaves you
- The transaction itself and its final terms
- Every system reviewed and its ongoing operation
- The decision on what gets disclosed to the counterparty
Where the line sitsA due-diligence audit produces one honest report on a deadline; what happens to the deal because of it is never ours to decide.
03From scope to one ranked report
Four stages, each closing on evidence
An audit that leaves a board unsure what to prioritise usually skipped one of these stages. This system closes each one with something the requesting party can act on directly.
Fix the scope and the standard
Which systems, which policies and which framework, if any, the audit measures against all get agreed before any review work starts.
Systems, policy and audience all fixed upfrontReview technical and process evidence
Configuration across the named systems and documented policy, where in scope, get reviewed together rather than as two separate exercises.
Configuration and policy reviewed side by sideRank every finding by real risk
Technical and process findings get ranked on one shared scale, so a board reads a single prioritised list rather than two competing ones.
One risk model, not two separate listsDeliver the single report
One written report closes the engagement, built to stand on its own for whoever requested it, whether that is an investor or a leadership team.
Delivered as one document, not a slide deck
04What actually moves the number
Four drivers, priced from the fixed scope
Security audits are priced against the agreed scope and depth, because these four factors change the review effort by multiples.
Number of systems in scope
A single product reviews faster than a portfolio of systems accumulated across several acquisitions.
Technical-only versus technical plus process
Adding policy review and stakeholder interviews extends the timeline beyond a configuration-only pass.
Whether a named standard applies
Measuring against a specific framework's control list takes longer than a general baseline health check.
Deadline driven by an external party
A transaction timeline compresses the schedule and can require additional reviewers to hit a fixed date.
05Evidence and proof
One report a board could actually act on.
Security audit proof is a ranked report that survived the board meeting without a follow-up call to explain it. Every record here waits for written client approval before production.
Explore case studiesA due-diligence audit delivered inside a two-week transaction window.
Aster North needed a full security picture for an investor within a tight closing timeline. A combined technical and process review delivered one ranked report before the deadline.
- Systems reviewed
- 11
- Report delivered inside deadline
- Yes
A logistics platform's first honest baseline in five years.
Tern had never commissioned a comprehensive security review across its stack. A baseline audit ranked findings across policy and configuration, giving leadership its first real prioritisation.
- Findings ranked in the baseline
- 31
- High-risk findings identified
- 5
One report told the board exactly where to spend first. No follow-up meeting needed to explain it.
Sample · pending client approval
06Read this first
When a single audit is the wrong answer
Commissioning a diagnostic report when what is actually needed is proof of exploitability or years of ongoing evidence work solves the wrong problem. The exits are marked plainly below.
- Penetration Testing
You need proof an attacker could actually get in
A risk ranking from a documentary review is not the same as a demonstrated exploit. An adversarial engagement answers that directly.
- Compliance Consulting
You need ongoing certification, not a single diagnostic
A standing programme of policy authoring and evidence collection toward an actual certification is separate, sustained work.
- Cloud Security
The exposure is narrowly cloud configuration
If nothing about policy or process is in question, a focused infrastructure review answers it faster than a full audit.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Technical-only audit | A fast internal baseline is needed | Which systems fall in scope | Configuration review and ranking |
| Full diagnostic | An external party needs one report | The framework and deadline | Technical and process review together |
| Repeat baseline | Tracking posture over time | How often to re-run it | Consistent method across cycles |
07Straight answers
Asked before the audit scope gets fixed.
01How is a security audit different from a penetration test?
An audit reviews policy and configuration and ranks the findings without attempting exploitation. A penetration test actively tries to break into an agreed scope and reports what actually worked.
02How is this different from compliance consulting?
This is a single, bounded diagnostic report. Compliance consulting is ongoing advisory work toward an actual certification, including policy authoring and continuous evidence collection.
03Do you review against a specific standard, or generally?
Both. A named standard like SOC 2 or an ISO information-security certification can anchor the review, or the audit can run as a general baseline with no framework attached.
04Can this support an acquisition or investment due-diligence process?
Yes, and the timeline gets built around the transaction's actual deadline. The report is written to be readable by a non-technical investor or acquirer.
05Do you review policy documents as well as system configuration?
Yes, when process review is in scope. Some audits stay technical-only when no policy exists yet or when the timeline does not allow for interviews.
06What happens after the report is delivered?
The engagement closes with the report itself. Any resulting remediation, ongoing testing or certification work runs as a separate, subsequent engagement.
07How long does a security audit take?
A technical-only baseline can close within a couple of weeks. A full diagnostic covering policy, process and several systems runs longer.
08What does a security audit cost?
Pricing follows the number of systems, whether process review is included, and whether a named standard applies, set during scoping. A repeat baseline typically costs less than the first one.