Insight: Compliance, Risk and Audit
Audit the environment. Rank what it finds. Recommend what to do.
This underpins nearly everything else a Chief Information Officer discusses. It is also widely misunderstood: audit treated as a review of logs, compliance treated as a concern for large enterprises, and risk treated as a conversation rather than a register. In practice the three form a single cycle, and it is the cycle that produces decisions a board can act on.
Illustrative rather than tied to a named client. Which standards apply differs by organisation; the method of assessing against them does not.
The Cycle
Three parts, in this order
They are frequently discussed as one subject, which is part of why they get deferred. Separated out, each has a distinct job and a distinct output.
First: Compliance
Establish which standards apply
Output: a defined benchmark
Before anything can be assessed there has to be something to assess against. What is required of this organisation, whether by law, by its industry, by its customers or by its insurers, determines the standard the environment is measured to.
Second: Audit
Examine the environment against it
Output: findings
Active engagement with the environment, not a review of documentation. Settings, configurations and controls are inspected directly and cross-checked against the standard, because what is configured and what is believed to be configured are routinely different.
Third: Risk
Rank the findings and recommend
Output: a register with decisions
Each finding becomes a documented exposure, ranked by the impact it would carry for this business, with a recommendation to remove or reduce it. The register is what turns a technical assessment into something a board can act on.
Why the size of the business is not the deciding factor
Compliance sounds like something for large organisations with dedicated teams, and that assumption is why smaller businesses carry more exposure than they realise. A twenty-person company still holds personal information, still signs contracts with security obligations attached, and still has to answer questions when something goes wrong. The obligations are proportionate to the organisation. The need to know what they are is not.
Step One
Which standards actually apply
Obligations arrive from several directions at once, and most organisations have never consolidated them into a single view. Select any source to see what it typically brings.
The level is decided by the requirement, not by ambition
An organisation supplying defence or working within a regulated supply chain may be required to hold a specific certification, and that requirement sets the standard absolutely. One with no such obligation gains little from certifying to the same level and will carry considerable ongoing cost for it. The correct benchmark is the one the business is genuinely held to, plus whatever the risk appetite justifies beyond it.
What is configured and what is believed to be configured are rarely the same.
Which is why an audit means opening the console, not reading the policy document that describes it.
Step Two
What an audit actually involves
Not a questionnaire, and not a documentation review. It runs in two modes that depend on one another: continuous monitoring that watches for movement, and human-led alignment checks that examine the environment directly against the agreed requirement.
Continuous monitoring
Logging and alerting that run constantly, watching for the things that indicate movement: a policy changed, a control disabled, access granted outside the normal route, activity that does not fit the pattern. This catches change as it happens, but it only reports what it has been configured to look for.
Alignment checks
Human-led review on a defined cycle, examining the environment against the compliance position the organisation has committed to. This is what finds the drift monitoring never flagged, because nothing alerted: the setting adjusted for a legitimate reason and never returned, the exception granted during a project and left in place.
Configuration inspected directly
Tenant settings, identity policies, endpoint compliance rules, firewall configuration, backup jobs, retention settings. Each examined in the console rather than accepted from a description of it, because the gap between the two is where findings live.
Cross-checked against the standard
Every control mapped to the specific requirement it satisfies. This is what makes a finding defensible: not an opinion that something looks weak, but a stated requirement the current configuration does not meet.
Evidence captured as it goes
Screenshots, exports and configuration records taken at the point of inspection, so the position at that date can be demonstrated later and the next audit has a baseline to compare against.
Gaps distinguished from weaknesses
A control that is absent, a control that exists but is misconfigured, and a control that works but cannot be evidenced are three different findings requiring three different responses. Collapsing them produces a register nobody can prioritise.
Neither mode works alone
Monitoring without periodic alignment checks reports faithfully on the things it was told to watch and stays silent about everything else, which is where compliance actually erodes. Alignment checks without monitoring establish a position accurately and then leave it unobserved until the next review, by which point the environment has moved again. Together they answer both questions worth asking: is it aligned now, and has it stayed aligned since.
Step Three
The register, and what makes it useful
A list of problems is not a register. A register ranks each exposure by what it would actually cost this business, and pairs it with a recommendation someone can approve.
Ranked by impact on this business
The same finding carries different weight in different organisations. A gap affecting a system the business cannot trade without ranks above one affecting a system it could lose for a week. Severity is assessed against the operation, not against a generic scoring table.
Every entry carries a recommendation
Each exposure is paired with a specific action to remove or reduce it, and where neither is proportionate, that is stated so the risk can be accepted deliberately. A finding without a recommendation transfers the problem rather than addressing it.
Cost and effort stated honestly
What the remediation involves, what it costs, and what it requires from the business. Without that, a board cannot weigh the exposure against the fix, and the register becomes a document that is read once and filed.
Owned, tracked and re-tested
Each item has an owner and a date, and completion is verified by re-examining the configuration rather than accepting that the work was done. An untested remediation is an assumption, and the register is a living document rather than an annual event.
The Point
Evidence, ranked, with a recommendation attached
Most organisations have reasonable intentions and a broadly sensible arrangement. What they usually cannot do is state what they are measured against, demonstrate where the current environment falls short of it, and say what each of those gaps would cost to close.
That is the whole of it: know the standard, examine the environment honestly against it, and turn what you find into ranked decisions with a price on them. Everything else in a governance conversation follows from having done that.