Custom baselines: adapting the audit to your context
No generic framework fits every organisation perfectly. Some controls do not apply to you; others, secondary in the standard, are critical in your context. A baseline is the agreed audit scope — and the object that makes an audit reproducible and defensible.
What a baseline is
A baseline is the agreed audit scope: which controls are in, which are set aside, and any level adjustments. You start from the standard catalogue — 318 controls on Entra ID and Microsoft 365, 176 on Active Directory — and adjust two things: which controls apply, and how much each one matters. The compliance score is then computed against your baseline rather than a generic default.
Two adjustments
Exclude what does not apply
If a service is not in use, or a control is genuinely out of scope, exclude it. This prevents dozens of irrelevant “non-compliant” results that would otherwise drag down the score and bury the findings that matter.
One nuance worth knowing: excluding what does not exist is pointless. A control with no matching object comes back compliant “not applicable” and does not penalise the score. Exclusion is for what exists but is out of scope — a domain being decommissioned, a service governed by another contract.
Adjust criticality
Reclassify a control as level 1 or level 2 based on your own risk priorities. A control the standard treats as hardening might be business-critical for you — raise its weight so the score reflects that.
The result: a score that reflects your real requirements, not a generic standard — and a report an auditor can see was applied deliberately, because the baseline is documented.
Start from a template, not from a blank page
Each tool ships normative templates that pre-select the controls answering a given framework, with counts computed from the real catalogue rather than hard-coded: seventeen templates on Entra ID and Microsoft 365, ten on Active Directory. CIS for a technical debrief, NIS2 or DORA when the stake is regulatory, ISO A.5 versus A.8 to separate organisational from technological measures.
Starting from a template matters for a reason that has nothing to do with saving time: it carries a normative rationale the client understands. “We audited against CIS Microsoft 365 Foundations” is a sentence that ends a discussion; “we picked a hundred controls” starts one.
What not to exclude
Two rules hold across the two referentials. Never exclude the fundamentals — role assignments, privileged accounts, the tier 1 controls of the maturity model — whatever the constraints; a scope that omits them is not an audit. And document every exclusion in the baseline description: at debrief time, that is what distinguishes a deliberate scope from an oversight.
Global vs client-specific baselines
A baseline can be global — reusable across all your audits — or client-specific. The latter is ideal for service providers and MSPs auditing several organisations with different requirements: one baseline per client, each reflecting that client's scope and risk appetite.
Traceability
The applied baseline is recorded in every report and in the audit history. Anyone reading the report can see exactly which controls were in scope and how they were weighted — essential for defending the result, and essential for comparing two audits: a run executed on a different scope is no longer comparable to the previous one.
A practical workflow
- Run a first audit on the full catalogue to see the whole picture.
- Identify controls that are genuinely out of scope and exclude them, with a written reason.
- Raise the criticality of controls that are business-critical for you.
- Save the baseline (global or per client) and re-audit against it.
- Freeze it for the duration of the engagement, and track the score over time — now measured against your real requirements.