Use this before every certification or surveillance audit, and whenever the scope, the product or the supplier list changes. You get two files in a new folder, ./soa-exclusion-justification-review/: a spreadsheet you can open in Excel with one row per control the company says does not apply, the tests it passed or failed, a verdict and a better-worded reason (exclusion-review.csv), and a short note summarising what should change and the questions for each owner (review-notes.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Reversing or keeping an exclusion is the approver's decision.

Inputs to gather

Read: the statement of applicability (security, privacy or AI extension), the scope statement, the risk register and treatment plan, the asset and system inventory, the supplier list with what each supplier does, records of processing or the AI system inventory where an extension is in play, and the documents the company shows customers (security questionnaire answers, trust page, contract security annexes). Ask the reader who approves the statement and whether any exclusion was challenged at a previous audit.

Step 1: list every exclusion with its current wording

Build the review spreadsheet (exclusion-review.csv) with one row per excluded control: control id (bare identifier), current justification verbatim, and the source path. Also pull rows marked partially applicable; a partial exclusion hides the same weaknesses. First reconcile the statement against the framework's full control list (from the licensed source or a framework lookup): a control that appears nowhere, neither included nor excluded, is a worse defect than a weak justification, so list missing rows first. Mark every exclusion challenged at a previous audit; repeating challenged wording unchanged invites the same finding.

Step 2: run six tests on each exclusion

Answer each test with a fact and a source, not an opinion: