Guide
What an IT Security Audit Should Actually Cover
Security audits vary enormously in depth. Some are a scan and a template; others examine configuration, evidence and process. Knowing the difference before you buy one saves both money and false confidence.
At a glance
- Scope should be agreed in writing before work starts
- Configuration review, not just automated scanning
- Findings rated by real risk, not tool severity
- A sequenced remediation plan is the deliverable
The domains a credible audit covers
Identity comes first, because identity is how nearly every modern intrusion succeeds. That means MFA coverage including exceptions, administrative account inventory and separation, conditional access policy, legacy authentication, dormant accounts and the leaver process that should have removed them.
From there: endpoint management and patch state, encryption coverage, endpoint protection deployment; network configuration including firewall rules, firmware currency, segmentation and remote access; cloud and SaaS tenant configuration, sharing defaults and application consent; backup coverage with evidence of tested restores; logging sources, retention and whether anyone reviews them; and vendor access, which is routinely the widest unreviewed permission in the environment.
- Identity, MFA, privilege and account lifecycle
- Endpoint management, patching and encryption
- Network configuration, firmware and segmentation
- Cloud and SaaS tenant configuration
- Backup coverage and restore evidence
- Logging sources, retention and review
- Vendor and third-party access
What separates a useful audit from a weak one
A weak audit runs a scanning tool and reformats the output. Every medium-severity finding looks identical, nothing accounts for compensating controls, and the recommendations are generic. It produces a document, not an improvement.
A useful audit reviews actual configuration, asks how processes run in practice, tests specific claims — can a leaver's account still authenticate, does a restore actually work — and rates findings by what they would mean for your organisation. It also states what was excluded, so the report is not mistaken for coverage it never had.
- Written scope, method and stated exclusions
- Configuration reviewed directly, not inferred
- Findings rated by business impact and likelihood
- Evidence cited for each finding
- Remediation sequenced by risk and effort
Questions to ask before commissioning one
Ask who performs the work and what their background is. Ask whether the assessors are the same people who manage your environment — if so, the review is not independent, and where a provider audits its own work that separation should be explicit.
Ask what the report contains, whether you get the raw evidence, whether remediation guidance is included, and whether re-testing after remediation is available. Then ask what happens if the audit finds problems the provider itself created; the answer tells you a great deal.
Keep exploring
Related Oakville services
Most engagements combine several of these. Follow the thread that matches the problem you are trying to solve.
Questions
Frequently asked questions
- How long does an audit take?
- Typically two to four weeks for a small or mid-sized environment, depending on scope, access and how much documentation already exists.
- How often should we audit?
- Annually for most organisations, or after significant change — a migration, an acquisition, a new compliance obligation or an incident.
- Is an audit the same as a penetration test?
- No. An audit reviews controls and configuration broadly; a penetration test attempts exploitation against a defined target. They answer different questions and complement each other.
Commission an audit with a defined scope
You will receive rated findings with evidence and a remediation sequence you can act on or hand to another provider.