02.08 Control Applicability and the Statement of Applicability

Why this matters

Install the Secure Controls Framework and you get several thousand controls. Install ISO/IEC 27001:2022 Annex A and you get ninety-three. Some meaningful fraction of them will not apply to you: you don't run the data center, you don't develop software, you have no industrial control systems, your cloud provider handles physical media disposal. The framework doesn't know that. It ships you the whole catalog.

What an auditor wants is not a shorter catalog. It's the reasoning. Which controls are in scope, which are out, and why each excluded one is out — written down, attributed to a person, and dated. That document is the Statement of Applicability, and for an ISO 27001 certification it's usually the first artifact the auditor asks for and the one they spend the most time on.

The trap is that most programs treat exclusion as a deletion. Someone deletes the controls that don't apply, the catalog gets tidy, and six months later nobody can answer "why isn't A.8.31 in here?" A deleted control leaves no record of the decision, no name attached to it, and nothing to review when the environment changes. Applicability exists so that scoping a framework down is an act that leaves a trail instead of a hole.

How frameworks describe this

ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection — Information security management systems — Requirements is the framework that makes this explicit. Clause 6.1.3(d) requires the organization to produce a Statement of Applicability containing the necessary controls, the justification for including each one, whether it's implemented, and the justification for excluding any Annex A control.

Read the clause carefully and the ordering matters. ISO derives controls from risk treatment first, then uses Annex A afterwards as a completeness cross-check. So "we included it because it's in the framework" is circular reasoning and auditors call it out. The justification an auditor accepts names a driver: a risk assessment result, a contractual obligation, a regulatory requirement, a customer commitment.

Other frameworks handle scoping less formally. SOC 2 scopes by Trust Services Criteria selection, and the criteria you don't select simply aren't in the report. NIST SP 800-53 uses control baselines (low, moderate, high) plus a tailoring process documented in the system security plan, where the tailoring rationale plays the same role a justification does. NIST CSF doesn't prescribe exclusions at all; the profile mechanism handles scope. SimpleRisk's applicability model is shaped by ISO's requirement because ISO's is the strictest, but the record it produces is useful under any of them.

How SimpleRisk implements this

Applicability lives on the Define Control Frameworks page in the Governance menu. Pick a framework in the rail on the left, and an Applicability column appears in the controls table on the right.

That column only appears when exactly one framework is selected. It's not a display quirk. Applicability is a per-framework decision, so under All frameworks the question has no single answer, and SimpleRisk would rather show nothing than average across frameworks that scope differently.

Applicable is the default, and applicable can now be argued

A control is applicable unless someone records a decision saying otherwise. Nothing is written when you install a framework, no backfill runs, and a 1,500-control catalog arrives as 1,500 applicable controls and zero stored decisions. Keeping the default free is what makes the model workable at that size.

What the default can't do is argue the case for one particular control. Clause 6.1.3(d) asks for a justification per control for inclusion as much as for exclusion, and for a long time every applicable control in the statement printed the same framework-level sentence. Ninety identical justifications is what invites an auditor to ask whether anybody considered the controls one at a time.

So an applicable control may now carry a record of its own. There are two ways to be applicable, and they produce different documents:

No record. The control is in scope and the framework's default inclusion justification speaks for it.
A record with the state Applicable. The control is in scope for these reasons and this sentence, both of which print against that control alone.

Neither field is required. The hint under the Applicable option in the modal says so: "In scope for this framework. A reason and a justification are optional; leaving both empty uses the framework's default inclusion justification." A taxonomy reason on its own is a complete answer, and so is a sentence of prose on its own. Forcing every applicable control to carry written prose produces filler, and filler makes the document worse rather than better.

One consequence catches people. Because an applicable control can now hold a record, choosing Applicable is no longer automatically an erase. It erases the record only when you save with the reasons unticked and the justification box empty. Clear the fields you want gone before you save; leaving a justification sitting in the box and switching the state back to Applicable keeps that justification, which is exactly the opposite of what "put this back in scope" usually means.

The two deviations

Not applicable means the control is out of scope for this framework. At least one reason and a written justification are both required, and that requirement is what makes an unjustified exclusion impossible to record rather than something a report has to go hunting for. SimpleRisk seeds six exclusion reasons: Not applicable to the defined scope, No such asset or technology, Function not performed by the organization, Legal or regulatory requirement does not apply, Risk accepted, and Covered by another control.

Inherited means somebody else performs the control on your behalf. A cloud provider, a managed service, a parent company's shared security function. What it requires is a Provider and a justification; the one reason it offers, Performed by a third party, is optional, because naming the provider is what carries the meaning. Inherited is not the same as not applicable and shouldn't be recorded as one: the control still matters to your risk posture, you just don't operate it, and an auditor will ask what assurance you hold over the party who does. Inherited controls are also still in scope, which means SimpleRisk expects evidence for them and reports an implementation status against them like any other applicable control.

Reasons are a list, not a choice

The reason field is Reasons, and it's a group of checkboxes rather than a dropdown. Its hint is one sentence — "Choose every reason that applies." — and it's there because the old single-select answered "how many may I pick?" by construction and a checkbox group doesn't.

A control is commonly included for more than one reason. Encryption at rest is in scope because a regulator requires it and because a customer contract names it and because the risk assessment landed on it. Ticking one of those three and stopping writes a statement that's true but thinner than the reasoning behind it.

The list is scoped to the state you picked, so the reasons offered for Applicable are the four standard inclusion drivers: Legal or regulatory requirement, Contractual obligation, Business requirement or best practice, and Results of risk assessment. Switching the state empties the group and repopulates it — a reason belongs to exactly one state, and one that survived a state change would be rejected on save. All three lists come from a lookup table your administrator can extend if your program has house categories.

The fourth inclusion reason is worth a note. Results of risk assessment was already implemented in substance before it had a name: an applicable control with risks linked to it has always cited those risks in its justification. Seeding it as a reason makes the reasoning explicit and puts it on the same footing as the other three.

Every state takes a Justification. The hint under the field is the standard to write to: "Appears in the Statement of Applicability. Write what an auditor would need to accept the decision." Two sentences naming a concrete fact about your environment beats a paragraph of hedging. "We operate no on-premises data center; all infrastructure runs in AWS eu-west-1 under the shared responsibility model" is a justification. "This control is not relevant to our organization" is not.

Recording a decision

There are two ways in, and they open the same modal.

For a batch, select controls with the row checkboxes; a selection bar replaces the toolbar, and Set applicability sits on it. For a single control, hover its row and use the scales icon in the row's actions — no checkbox needed. Both entry points appear only when the rail has one framework selected, for the same reason the Applicability column does: under All frameworks there is no framework for the decision to belong to.

The modal's one card is headed Decision. Inside it: an Applicability segmented control carrying the three states, a Reasons checkbox group that repopulates from the state you picked, a Provider field for inherited controls, and the Justification box. An amber note near the top spells out both halves of the scope: which framework the decision belongs to, and which controls are about to receive it. The framework half reads "This decision applies only within [framework]. The same control can stay applicable in another framework."

That second sentence is worth reading twice. A control shared across ISO 27001 and SOC 2 can be excluded from one and in scope for the other, and that's usually correct rather than an inconsistency to clean up.

The second half of the note has three spellings, because there are three things you might be acting on. The header checkbox takes the current page. Select all, which names the full count in its own label, escalates to every control matching the current filters, including the ones on pages you haven't looked at. On a filtered view of a large framework the difference between those two is the difference between writing twenty-five decisions and writing fifteen hundred, so the note names the number explicitly before you commit. Opened from a row, the modal names that control instead — in its title and in the note — and writes to it alone, whatever happens to be ticked at the time.

Once saved, the decision shows as a chip in the Applicability column. Expanding a control's row detail shows the record behind a deviation: the state, the reasons joined into one line, the provider, the justification, plus Decided by and Decided on. Attribution is the point. You may be defending this decision to an auditor two years after the person who made it left the company.

An applicable control's own reasons and justification aren't shown in that row detail yet — the drawer prints the state alone for anything in scope. To read back what an applicable control has recorded, reopen Set applicability from its row action: opened on a single control, the modal prefills from what's stored, so the reasons come back ticked and the justification comes back in the box. Opened from the selection bar it doesn't prefill at all, and that's deliberate. A bulk selection has no single stored decision to show, and filling the form from whichever control happened to be first would state a decision about controls you never looked at, to all of which the modal is about to write.

Writing applicability needs the Able to Modify Existing Frameworks permission. Reading it only needs governance access.

Finding excluded controls again

Two surfaces exist for this. The filter sheet gets an Applicability facet once a framework is selected, filtering to Applicable, Not applicable, or Inherited. The insights band above the table gets an Excluded tile, subtitled Not applicable or inherited, that drills through to exactly that filtered view. Under All frameworks the tile reads an em dash and says Scope a framework to decide, for the same reason the column disappears there.

Reviewing excluded controls on a cadence is the habit that separates a maintained SoA from a stale one. Environments change. The control you excluded because you had no software development function becomes applicable the quarter you hire your first engineer.

The framework-level SoA fields

Two fields on the framework itself, in the Statement of applicability card of the add and edit framework modals:

Scope statement — the scope this framework is certified against. This is the ISMS scope in ISO terms, and it belongs on the SoA cover page. Write the real boundary: which legal entities, which sites, which systems, which services. It's a rich-text field, the same editor the framework description uses, because a real scope is usually a sentence or two followed by a list of the entities and systems inside the boundary. Bold, italics, bullets and numbered lists all survive onto the cover page and into the PDF. The spreadsheet export flattens them, since a cell can't hold formatting — paragraphs come across as line breaks and list items as bulleted lines, so the structure reads even there.
Default inclusion justification — how inclusion was determined for controls that are simply applicable. The field's hint is "Name the driver, not the framework," which is the circularity warning from clause 6.1.3 in shorter words. New frameworks arrive with a default sentence already in the box — "Determined by the organization's information security risk assessment and retained as a necessary control" — which you should read as a starting point and replace with your own. It names the driver, so it isn't wrong; it isn't specific to your program either.

The scope statement is left empty on frameworks that already existed before you upgraded, because there is no boilerplate that could be true of somebody else's ISMS scope. The default inclusion justification is filled in for them, with the same sentence a new framework gets. Neither field is required to save a framework, and clearing either one is allowed — a framework with no inclusion justification of its own falls back to that same sentence in the report rather than printing a blank column.

Generating the Statement of Applicability

Everything above is input. The document itself is at Reporting → Reports → Statement of applicability, and there are two faster routes to it from the framework you're working on: the Generate SoA button in the controls toolbar, and the same action in each framework's row menu in the rail. The toolbar button appears only once you've selected a framework, because an SoA is written about one framework at a time — the same reason the Applicability column and facet are absent under All frameworks. Its label is short because it shares that row with + Add control: hover it for the full "Generate statement of applicability", and at narrow widths it folds down to its shield icon alone.

All three routes land on the same launcher. Opened from the Reporting Hub, which can't know which framework you mean, it starts with an empty picker: choose a framework from the searchable dropdown, where each option shows how many controls it holds. Opened from the toolbar button or the rail's row menu, the framework you clicked arrives already chosen, and the three buttons are there with nothing further to pick.

The launcher rather than the document itself, because everything you can produce is offered in one place — the browser view and both exports. A button that went straight to the browser view would leave the exports somewhere you had to back out of the document to find.

Open is always there. If your instance has the Import-Export Extra, two export buttons join it: XLSX and PDF. The three read as one word each because the row itself supplies the verb, and because PDF cannot honestly carry one — above five hundred controls it opens a print view rather than downloading a file. All three produce the same document — same controls, same columns, same counts on the cover, same legend — because they come from one assembly rather than from several queries that ought to agree. Every one of them is searchable text rather than a picture of a page, which matters when an auditor is working through a thousand controls. Without the Extra neither export button is there at all; reading the statement never requires it, and you can still print the browser view with your browser's own print command.

The workbook arrives as five tabs rather than one long sheet: Cover, How to read this statement, Statement of Applicability, and one for each appendix. That's worth knowing because of what it lets you do to the middle one. The register's header is the first row of its own sheet, so it comes with a filter on every column and the header frozen — which means "show me everything reading No" is a dropdown rather than a read of fifteen hundred rows. On the old single sheet the header sat a dozen rows down under the cover block, and a sort dragged the cover into it.

There is exactly one PDF button, and there is one at every framework size. That is deliberate rather than incidental: the SoA is a controlled document, and two PDF buttons would mean two people could hand an auditor two different-looking PDFs of the same statement depending on which one they happened to click.

What changes with size is the machinery behind that button, not the button. Up to five hundred controls, SimpleRisk renders the PDF on the server and sends you the file. Above that, the same button opens the chrome-free document and raises your browser's own print dialog on it, already set to landscape Letter, and the browser writes the PDF — because the server-side renderer's memory grows with the control count and exceeds what a typical PHP memory_limit allows somewhere past eight hundred. On the frameworks SimpleRisk ships, only the two Secure Controls Framework catalogs are in the second regime; the next largest is ISO 27002 at a little over three hundred. Both routes pin the same columns at the same widths, so the register reads identically either way. Where they differ is what runs along the top and bottom of each page, and it matters if your process cites page numbers. The server-rendered PDF carries a running header on every page, with the document title on the left and the framework on the right, and it numbers every page in the footer (Page 3 of 38) regardless of which browser you started from, because the server draws both. The browser-printed statement has no running header, and whether it gets page numbers is up to the browser: Chrome and Edge honor the instruction, Firefox and Safari ignore it and produce an unnumbered document. So a page that gets separated from a server-rendered statement can still be identified and put back; one from a browser-printed statement can't always be. If that matters to your evidence handling and you're above the five-hundred-control line, print from Chrome or Edge. The spreadsheet export is unaffected at any size.

What the document contains

Six columns, and two appendices after them.

The columns are Reference, Control Name, Applicability, Justification, Implementation Status and Evidence — the clause 6.1.3(d) minimum plus evidence. Appendix A carries every control's justification in full, and Appendix R the remediation plan behind every failing control. Both are numbered in the order the rows appear, so A17 and R3 are findable by counting down the table, and the numbering is identical in the browser, the PDF and the spreadsheet.

Width is why the long content sits in appendices rather than in the table. Nine columns doesn't fit a landscape page — it runs about a quarter of its width off the right edge, and the overflow doesn't wrap or scale, it clips. Moving the justifications and the plans out of the register brings it inside the page with nothing lost, since the appendices print the text in full. It also matches how the standard hands these over: 6.1.3(d) is the statement and 6.1.3(e) is the risk treatment plan, so a marker into a numbered plan is closer to what an auditor expects than a paragraph wedged into a row.

Two things you might expect and won't find. There's no control owner column — no clause asks for one and it's a click away on the control itself. And there's no review cadence column; a control with three tests has three schedules, so each test's next date rides on that test's own line in the Evidence column, which is the only place it can be unambiguous.

Risk linkage is in the document, in Appendix R: each entry names the risk ID beside the planning date, the mitigation owner and the percent complete. That's more traceability than a column of bare IDs, and it's attached to the failure it explains.

The document itself

Open opens the statement in a new tab, and that tab has no sidebar, no top bar, and no breadcrumb. (Above five hundred controls, PDF opens the very same tab and adds the print dialog; nothing else about the document differs.) This is deliberate: the SoA is an artifact you print, save, and hand to an auditor, and application furniture is noise in all three. Because there's no shell to identify it, the document identifies itself — your organization name, the framework, and the generation timestamp sit at the top of the cover. A link back to the launcher sits at the bottom, and it doesn't print.

A link straight to ?framework={id} gets exactly the same chrome-free document, so a bookmark or a link you send to an auditor behaves identically to Open. Add &print=1 to have the print dialog come up on arrival — which is exactly what PDF links to on a framework too large for the server-side renderer. The launcher's own preselection uses a different parameter, ?preselect={id}, which lands you on the launcher with that framework chosen rather than on the document. That's the one to use in an internal link if you want the person following it to pick the export format themselves.

The report is assembled the moment you ask for it. There's no stored SoA to go stale, and no "generate" step that has to be re-run after you change a decision.

The cover carries the framework's name, the scope statement, and five counts: total controls, applicable, not applicable, inherited, and excluded (the last being the two deviations together, matching the Excluded tile on the controls page). Under the cover, before the table, comes the legend. Then one row per control, and the two appendices after them.

The six columns:

Reference — the clause numbers this framework cites the control by, not the control's own number. That distinction matters on any catalog whose controls come from somewhere else. If your ISO 27002 framework was built from the Secure Controls Framework, the control SimpleRisk knows as GOV-01 appears in the ISO statement as 5.1, 5.4, 5.37 — the three ISO clauses it satisfies — because those are the references an auditor is working from. One control frequently satisfies several clauses, and all of them are listed, in clause order. A control the framework carries with no reference of its own falls back to its SimpleRisk control number rather than printing an unlabeled row.
Control Name — the framework's own title for the control where the framework supplies one, with the SimpleRisk control's name beneath it in smaller type. Two names because a reader needs both: the standard's wording to read the document against the standard, and the SimpleRisk name to find the control in the application afterwards. Where the framework hasn't supplied a title, the SimpleRisk name stands alone.
Applicability — Applicable, Not applicable, or Inherited, shown with the same state pill the controls table uses.
Justification — never blank, and it resolves in four steps. A deviation prints its own written justification, along with the reason, the provider where there is one, and who decided it when. An applicable control that recorded its own reasoning prints that: the reasons joined together, the freeform sentence, or both. An applicable control with nothing of its own cites the risks whose treatment names it, if any are linked. Failing all of that, it falls back to the framework's default inclusion justification, and to the standard default sentence if the framework has none. The default inclusion justification is deliberately not repeated on the cover — clause 6.1.3(d) asks for the justification against each control, and printing the same sentence once above the table and again on a thousand rows says nothing the rows haven't.
Justification also carries a marker like [A7] pointing at that control's full justification in Appendix A. The cell prints the opening of the justification — about ninety characters — because on the ISO 27001 catalog fifty-one controls share twenty-seven distinct justifications and one 375-character paragraph appears twenty-five times. Nobody should have to read the same paragraph twenty-five times to find the one that differs. The complete text of every control's justification is in the appendix, including the ones identical to twenty others': the appendix is the record, and a record that says "same as A1" makes the reader prove the sameness themselves.
Implementation Status — one of six states, described below. It's a column of its own rather than a line stacked above the evidence, for the reason an auditor's first pass is usually "which controls are not implemented" — that's a finger down one narrow column, and it only works if the pills line up with each other.
Evidence — what substantiates the control, also described below. Separate from the status beside it, and deliberately so: the status is computed from tests alone, so a confirmed policy listed here fed no part of it. Stacking the two implied a derivation that doesn't exist.

The Implementation Status column, and why there are six answers

The old rule read a control's maturity: at or above target meant implemented, below target meant partial. That was the wrong signal in both directions. Sitting below a stretch maturity target isn't a control failure, so a control that operates perfectly printed Partial and understated the organization's position. Worse, a control nobody had ever tested printed Yes on the strength of a maturity number somebody typed in a year ago.

Implementation status now comes from the control's tests and their most recent results, and from nothing else. Maturity is still a first-class idea everywhere else in SimpleRisk; it simply stopped answering a question it was never evidence for.

Yes: Every test defined for this control passed when it was last run.
Partial: The control's tests disagree: at least one passed, and at least one failed or produced no verdict.
No: No test of this control passed when it was last run, and at least one failed.
No tests defined: No test has been defined for this control, so its operation has never been verified. A governance gap: nobody has decided how this control is checked.
Tests never run: Tests exist for this control, but none of them has ever been run. An operational gap: the checks were decided and have not been carried out.
N/A: The control is excluded from this framework's scope, so it has no implementation status.

The last two unverified states are one distinction, and it's the distinction the whole set exists for. "Nobody decided how to verify this" and "somebody decided and it didn't happen" are different findings with different owners — one belongs to whoever runs the compliance program, the other to whoever was supposed to run the test. Folded together into a single "not verified" you can't tell which one you have, and the remediation for each is nothing like the remediation for the other.

Neither of them is No. Declaring a control not implemented because you never looked at it is a false statement against yourself, in a document you attest to, and auditors treat an honest "not yet verified" considerably better than either that or an unevidenced Yes.

A seventh value, Status unavailable, exists and should never appear. It's what the document prints if it's handed a status it can't label — a software defect, and the legend says so in as many words rather than letting the reader take it as an admission about the control.

The asymmetry is deliberate

Read the table closely and Yes and No aren't mirror images, which looks like a bug and isn't. One test that passed beside one that has never run reads Partial. One test that failed beside one that has never run reads No.

The rule underneath is directional: missing evidence must never improve the reported position. Yes is a claim in your favor, so incomplete evidence has to block it — otherwise the document claims full implementation on partial evidence. No is a claim against you, so incomplete evidence must not soften it — otherwise an unrun test upgrades a confirmed failure to Partial, an auditor reading Partial investigates less than one reading No, and the absence of information has made a real failure look better than it is.

Where two readings are both defensible, a compliance artifact reports the less flattering one. That's what makes the document worth anything.

An Inconclusive result is treated the same way a never-run test is: it produced no verdict, so it blocks Yes. On its own it doesn't produce No either, because there's no failing verdict to be conservative about, and inventing one would be understating in the other direction.

Retired tests are excluded from all of this. Retiring a test is a decision that the check is no longer performed, so a retired failure can't drag a control to Partial forever, and retiring a control's last remaining test doesn't leave its old verdict standing — the control drops to No tests defined, which is the truth about it.

Overdue

Overdue is a marker, not a status. It composes with Yes, Partial, or No, and it means at least one test that actually contributed a result to that verdict is past its own next test date. The result shown still stands. The test genuinely did pass, or genuinely did fail; only its currency is in question, and discarding a real result to say "unverified" would lose information the reader needs.

A test that has never run doesn't raise the marker, even when its date has gone by. It produced no evidence, so it has no evidence whose currency could be stale, and its gap is already reported in the Implementation Status column.

SimpleRisk holds no opinion about what "stale" means. Six months for one organization is two years for another, and it can vary test by test — so currency comes from each test's own schedule, and there's no product-level threshold anywhere. A test whose schedule sets no next date is never overdue, which is the right answer rather than a stamp on every control that simply has nothing scheduled.

The marker is loud on purpose: a word rather than a symbol, a filled block on its own line, a warning glyph so it survives a monochrome printout, and a rail down the whole row so it's findable while skimming. An auditor working down a column of Yes must not be able to overlook that the evidence behind one of them is three years old. A marker that's easy to miss looks like disclosure while functioning as concealment, which is worse than not having one.

Evidence, and the two kinds of nothing

Evidence covers design and operation both. Policies show that the control was designed; tests show that it operates. The Evidence column carries both:

Linked documents — the governing documents mapped to the control. Confirmed mappings only, never the unreviewed candidates the AI and keyword matchers propose.
Tests that produced a verdict — a test that has never run substantiates nothing, so it isn't listed here; its gap shows up in the Implementation Status column instead.

Each piece of evidence is its own bullet, marked with what it is: a tick for a test that passed, a cross for one that failed, a neutral dot for a test that reached no verdict, and a section sign for a governing document. A document carries no verdict — it either exists and is linked or it doesn't — which is why it doesn't get a tick it hasn't earned. A test's bullet also carries the date it last ran. The four marks are defined in the legend, and they're the same four in the browser, the PDF and the spreadsheet.

The marks do real work here rather than decorating the column. Comparing verdicts down a column of names is what a reader is actually doing, and "Compliance Obligation Register Review — Pass (2026-07-02)" buries the one fact they want in the middle of a string. Where the legend can't name a result, the word is still printed beside the mark. That covers a locale spelling its results differently and a result state newer than the build, so the mark is never the only channel.

What the column deliberately does not report is whether the evidence a test declared it required actually arrived. That sounds like a stronger claim than it is: all SimpleRisk could measure is whether a file was attached to the audit, which says nothing about whether anybody assessed it and has no bearing on whether the test passed. Plenty of programs keep their evidence outside SimpleRisk entirely, and a check like that can't tell them from a program that collected nothing. Whether a test's paperwork is complete is a question about the test, and Define Tests is where you'll find it.

The column is never simply empty, because two different absences would then look identical while meaning opposite things.

A not applicable control prints a quiet em dash. No evidence is expected of a control that's out of scope, so the absence is correct.

An applicable control with nothing behind it prints No evidence linked, in words, marked. The control is in scope, may be claimed implemented, and nothing substantiates it. That's the first thing an auditor circles, and rendering it as an empty cell hides it.

Inherited controls get the loud version, not the quiet one. A provider performing the control doesn't put it out of scope, and softening the absence there would let "somebody else does it" become a synonym for "nobody checked."

The two appendices

A control reading Partial or No raises the next question immediately: what are you doing about it, and by when? Appendix R — Remediation plans answers it. The control's row carries a marker like [R3] on its status, and the entry under that marker gives every failing test, its result and date, its summary, the risks it's linked to, and for each risk the planned mitigation date, the mitigation owner, and the percent complete.

Every failing test, not the first one. And a failing test linked to no risk is called out as No risk linked rather than dropped for want of something to join to, because that's the most serious thing the appendix can report: the control failed and no treatment plan traces back to it. Dropping the entry would render it as a blank, and a blank reads as nothing to report.

This is the SoA pointing at the risk treatment plan, not becoming one. Clause 6.1.3(e) asks for the treatment plan as a separate document; what an auditor expects of the statement is that an unimplemented control is traceable to a plan with an owner and a date. A framework in good health prints no Appendix R at all — an appendix with no entries doesn't get a heading over nothing.

Appendix A — Justifications works the same way and is always there, because every control has a justification. Both appendices are numbered in the order the rows appear, so A17 and R3 are findable by counting down the table, and the numbering is identical in the browser, the PDF and the spreadsheet.

Putting the plans after the register rather than under each control fixed two things. A count of the table's rows is the control count again, which is the number the cover and the controls grid are reconciled against — the old sub-rows broke that. And it matches how the standard hands these over: clause 6.1.3(d) is the statement and 6.1.3(e) is the treatment plan, so a marker into a numbered plan is closer to what an auditor expects than a paragraph wedged into the register.

The legend

Six statuses, three markers and four evidence marks is more vocabulary than the Yes/No/Partial an auditor arrives expecting, and an undefined vocabulary invites the reader to guess — unfavorably. So the statement carries a legend defining every value it can print, and it's the same legend in all three formats.

It's grouped by the column each value appears in — Applicability, Implementation Status, Evidence, then Appendix R — under that column's own heading. Look up the column you're reading and you get a closed set, which is the question you actually have in front of a cell you don't recognize.

Three more details make it useful rather than decorative. It sits above the table, not below it, because a key trailing fifteen hundred rows is a key nobody scrolls back to. Each entry shows the actual mark — the same pill, the same overdue badge, the same em dash, the same bullet mark the rows use — rather than describing it in words, so the reader matches graphics to graphics at a glance. And the list is complete rather than filtered to the values that happen to occur in this particular framework, so two generations of the same document can be diffed against each other.

The three statuses that aren't verdicts are worth reading in the legend rather than guessing at. No tests defined, Tests never run and Status unavailable all sit under an "Implementation Status" heading, and none of them means the control is absent or failing — each one says, in the legend's own words, that implementation isn't demonstrated here. The first two are gaps in your verification, and the third is a defect in SimpleRisk.

The report's counts come from the same query that draws the controls table, so the total on the cover always equals the count above the controls grid for that framework. If they ever disagreed, one of them would be wrong in an audit.

Two things the report will refuse. A framework with no controls mapped into it says so rather than printing an empty table. An Inactive framework is refused outright with an explanation: an SoA states the scope an organization currently operates under, and a framework you've deactivated has been withdrawn from the program. Reactivate it if you need the document.

If the framework's scope statement or default inclusion justification has never been filled in, the report says so in a note above the table and links you to the framework to add them. It still renders the rows — the document is worth reading either way — but an SoA with no stated scope is the first thing an auditor asks about. The note about the inclusion justification is a nudge rather than a defect report: the Justification column falls back to the standard sentence, so nothing is blank, but a generic sentence isn't your organization's and an auditor reading a thousand identical rows is entitled to ask whose risk assessment it refers to.

Common pitfalls

Deleting controls instead of excluding them. This is the one that costs the most, and it's the one you can't take back. Deleting a control is permanent — there's no undelete, no archive to fish it out of, no restore action. A deleted control leaves no reason, no justification, no author, and no date, so the exclusion decision is unreviewable and unauditable. It also breaks cross-framework mappings, because the control is gone from every framework it was mapped into rather than scoped out of one. (Test results recorded against it are retained for audit history, but that's the test records surviving, not the control.) Exclude, don't delete.
Excluding the whole framework when you meant to exclude a section. Programs sometimes mark a framework Inactive to get it out of the way, then discover reporting has gone quiet for controls they actually operate. Inactive is the right lever for a framework you're not pursuing at all. Applicability is the right lever for the parts of a framework you're pursuing that don't fit your environment.
Writing the justification for yourself instead of for the auditor. "N/A," "not relevant," and "see scope doc" are the three most common justifications we see, and none of them survives a question. The auditor doesn't have your context. Name the fact: no data center, no card data, no development function, no employees in that jurisdiction.
Using Not applicable where Inherited is correct. If AWS performs your physical media destruction, the control isn't inapplicable to you — it's inherited, and the auditor's follow-up is about the assurance you hold over AWS rather than about your scope. Recording it as not applicable invites a finding, because on its face you've claimed a control that clearly matters doesn't.
Forgetting that Select all crosses pages. The selection bar's Select all applies to every control matching the current filters, not the page in front of you. Read the count in the amber note before you save. Undoing a bulk exclusion means another bulk operation, and the audit trail keeps both.
Expecting Applicable to wipe the record. It did once. Now an applicable control can hold reasons and a justification of its own, so saving with Applicable selected only resets the control to the framework default if you've also unticked the reasons and emptied the justification box. If you meant to strip a control's per-control reasoning back to the framework's sentence, clear both fields first and watch for the toast — "Applicability reset to applicable" means the record went, "Applicability updated" means one was written.
Reading No tests defined as a small problem. On a freshly installed framework it will be most of your controls, and it looks like a display issue rather than a finding. It isn't. It's the statement telling an auditor that nobody has yet decided how these controls get verified, which is a governance gap in clause 9's terms and one they will ask about. The fix is in Define Tests, not on this page.
Ignoring the Overdue marker because the verdict still reads Yes. It does still read Yes, and the pass was real. What's stale is the evidence. An auditor who spots an overdue marker on a control you've claimed implemented will ask when it was last actually checked, and "the schedule says quarterly and it's been eighteen months" is a worse answer than a recent Partial would have been.
Treating the SoA as a certification-week deliverable. The Statement of Applicability is a living document in the standard's intent and a snapshot in most programs' practice. Recording each exclusion when you make the decision costs a minute. Reconstructing four hundred of them the week before the stage 2 audit costs a fortnight, and the reconstructed reasoning is visibly reconstructed.