The argument
N/A Is a Conclusion, Not a Vanishing Spell
A not-applicable conclusion is defensible only when current facts show why the requirement, system, channel, or responsibility does not apply—and when changes can trigger reconsideration.
The field pattern
A requirement is marked N/A because the process is outsourced. The provider performs part of the activity, the entity configures the service, and neither party’s evidence covers the handoff. The label removed the worksheet row from review. It did not remove the responsibility.
Why it matters
N/A Alchemy hides unresolved reasoning at exactly the point where the assessment record appears most certain. The underlying facts may support the conclusion, contradict it, or show a shared responsibility that needs evidence; the label alone cannot tell which.
A good N/A record is compact but traceable. It names the applicability question, relevant facts, architecture or process boundary, dependencies, owner, supporting evidence, limitations, review date, and change conditions.
Questions that expose the Wack
- What current fact makes this requirement or activity not applicable?
- Does a provider perform the activity, or is the activity genuinely absent from the environment?
- Which configuration, boundary, service, or business-process change would invalidate the conclusion?
- Who owns reviewing that trigger and retaining the supporting evidence?