Audit tailoring

Real audits are rarely run against the whole catalogue. A framework ships requirements that do not apply to your perimeter, that a customer has explicitly carved out, or that a contract puts out of scope. Audit tailoring lets you exclude those requirements from a single audit so they stop counting toward its score, its progress and its roll-ups — while the requirement rows themselves, and anything already recorded on them, stay exactly where they are.

Where to find it

On an audit’s page, in the Associated requirements panel: the Exclude requirements and View excluded buttons sit next to the Filters button.

Excluding requirements

Click Exclude requirements. The tree switches into exclude mode and a checkbox appears beside every node, with the banner Select requirements to exclude, then click Validate.
Tick the requirements you want out of scope. Ticking a section heading selects its assessable descendants too, so a whole chapter can be dropped in one click.
Click Validate to apply, or Cancel to discard the selection and leave the audit untouched.

Nothing is written until you press Validate — the ticks are a pending selection held in your browser. The button label changes to Exit Exclude Mode while the tree is in exclude mode.

Reviewing and undoing exclusions

View excluded opens a panel listing every requirement currently excluded from this audit. Each line can be put back with its own undo action, or you can select several (or use the select-all toggle) and undo them together. Restoring a requirement brings its previous result, score, observation, applied controls and evidence back with it — exclusions never delete a requirement assessment, they only hide it from the arithmetic.

Why the totals change

Exclusions are applied wherever the audit is summarised:

The global score ignores excluded requirements, so the average or sum is computed over a smaller set. Both the number and the denominator move.
Progress drops excluded requirements from its total, so an audit can reach 100% without every framework requirement being answered.
The donut charts and the status counts on the audit page, and the roll-ups those feed, count only what is still in scope.
Excluding a non-assessable parent node cascades to every assessable requirement underneath it.

Excluded requirements still appear in the requirement tree — they are removed from the measurement, not from the document. Expect the score to jump the moment you validate, and re-read it before quoting a number.

Tailoring versus the alternatives

Three mechanisms narrow an audit, and they are not interchangeable:

Mechanism	What it means	Use when
Exclusion	This requirement is not part of this audit at all	A contract, a customer or a scoping decision removes it
Result Not applicable	The requirement is in scope but does not apply here, and that is a finding worth recording	An assessor should see the judgement and its justification
Implementation groups	The framework’s own scope or maturity tiers	The standard already defines the slice you committed to

Prefer implementation groups when the framework offers them, since they are part of the standard and travel with every report. Prefer Not applicable when an auditor needs to see the reasoning. Reach for exclusion when neither fits.

Who can do it

Applying or undoing exclusions is a write against the audit, so it needs an editing role in the audit’s domain. Anyone with read-only access to the audit — including third-party respondents answering a questionnaire — cannot change the scope. The change is scoped to one audit: excluding a requirement here has no effect on any other audit using the same framework, and no effect on the framework in the catalog.

Audits — the requirement tree and what feeds the score.
Multi-level support — narrowing scope through implementation groups instead.
Exports — what a tailored audit looks like on the way out.