Applicability

The Applicability module is where you record the explicit decision that something applies, doesn’t apply, applies conditionally, or has been deferred. Auditors don’t only care about what you’re doing; they care about what you’ve decided not to do and why. Applicability is the audit trail for those decisions.

Whenever a framework requirement, a regulatory obligation, a published policy, or an evidence requirement is in front of you and the team needs to answer “does this apply to us?”, the answer (and the reasoning) belongs here. The decision is captured once, signed by an approver, given an expiry or review date, and connected back to the thing it’s about.

When you would reach for this

You set up applicability decisions when:

A framework like a Statement of Applicability requires you to declare which controls you’ve adopted and which you haven’t, with justification.
A regulator publishes an obligation and you need to record an explicit decision that it does or does not apply to a part of your organization.
An auditor asks “why aren’t you doing X?” and you need a defensible written answer.
A control or requirement is temporarily deferred (e.g., during a transition period) and you need an audit trail of when the deferment was approved, who approved it, and when it expires.
A part of your organization inherits a parent organization’s applicability decision and you want to record the inheritance explicitly.

You don’t reach for this when implementing a control (that’s Controls), capturing evidence (Evidence), or recording a waiver from an active control (that’s Exceptions). Applicability is about whether something applies in the first place.

What lives in an applicability decision

A single record type:

Applicability decision carries:

A subject (the thing being decided about): a control, an obligation, an evidence requirement, a report, an AI configuration, a third-party requirement, a policy. Identified through neutral subject refs (module key, resource type, resource id), so any governed object can be the subject.
A decision kind: applicable, not-applicable, deferred, inherited, overridden, conditionally-applicable, unknown. Free text on your side; the product doesn’t enforce a fixed list.
A justification: the reasoning, captured as encrypted text. Long-form prose explaining why this is the decision.
An approver and a reviewer: responsibility assignments naming who made the call and who validated it.
A methodology or template snapshot: the framework, internal policy, or decision template that drove the decision shape.
An expiry date and a review-due date: when the decision lapses or needs reconfirmation.
A decision snapshot: any additional structured evidence the decision relies on.

Decision kinds

The common decision kinds and what each one means in practice:

Kind	Meaning
`applicable`	This subject applies. The organization will implement, comply with, or pursue it.
`not-applicable`	This subject does not apply. The justification explains why (out of scope, no relevant assets, prohibited by another policy, etc.).
`deferred`	The applicability decision is intentionally postponed to a future date. The expiry/review date matters.
`inherited`	The decision is taken from a parent organization, framework, or program; the local org accepts it without making its own.
`overridden`	An inherited or previously-recorded decision is being explicitly overridden at this level.
`conditionally-applicable`	Applies only when specified conditions are met. The justification spells out the conditions.
`unknown`	A placeholder decision while information is being gathered. Should have a short review-due date and should not stay `unknown` indefinitely.

Use the vocabulary your organization is most comfortable with; the kind is free text.

A worked example: a logistics company prepares a statement of applicability

A logistics company runs warehousing and last-mile delivery across multiple operating regions. They’re preparing for a first-time certification audit against an international information security framework, and the framework’s required deliverable is a Statement of Applicability (SoA) declaring, for every Annex A control, whether the company has adopted it and, if not, why.

Their compliance program manager, Diego, uses Applicability like this.

Step 1: walk the framework. Diego opens the framework version in Frameworks and goes through every leaf node (each Annex A control). For each one, the team has already had an internal discussion; the question is now to record the outcome.

Step 2: create an applicability decision for each leaf. For each framework node, Diego creates an applicability decision. The subject is the framework node (or, more commonly, the corresponding internal control where one exists). He marks the decision kind:

For controls the company has implemented, the decision is applicable and the justification points at the implementing internal control.
For controls the company has explicitly not adopted, the decision is not-applicable and the justification explains why (no in-scope assets, addressed by a compensating control elsewhere, etc.).
For a small number of controls under active discussion, the decision is deferred with a 90-day review-due date.

Step 3: approver routing. Each applicability decision is routed to a named approver: the CISO for security controls, the DPO for privacy-adjacent controls. The approver’s responsibility assignment is recorded on the decision; the audit log shows who signed off and when.

Step 4: methodology snapshot. Diego attaches the company’s internal “applicability assessment methodology” document to each decision through the methodology snapshot field, so an auditor can see not just the answer but the framework that produced it.

Step 5: export for the auditor. When the auditor arrives, Diego can show:

Every framework node, with its applicability decision next to it.
The approver and timestamp on each decision.
The justification text.
For deferred decisions, when they will be revisited.

A year later when the framework publishes a new version, Diego doesn’t re-do every decision; he creates new applicability decisions for new framework nodes only. Old decisions stay tied to the old version and remain valid for any in-progress audit cycle.

What you’ll see in the product

Applicability lives under Governance → Applicability in the workspace.

The Applicability list shows every decision recorded, filterable by status, decision kind, approver, subject module, and date range. It’s where you’d start when an auditor asks “show me your not-applicable decisions and the justifications.”

Inside a decision, you see the subject, the kind, the justification, the approver, the methodology snapshot, the expiry and review dates, and the audit trail of any changes.

Inside other modules (controls, obligations, evidence requirements), the current applicability projection appears as a field on the record, so you can see at a glance “this control is applicable / not-applicable” without leaving the page. Clicking through takes you to the full decision history.

Every applicability decision is captured in the workspace Audit Log.

Expiry and review

Applicability decisions don’t last forever. Use the expiry date for decisions that should automatically lapse (e.g., a 90-day deferment), and the review-due date for decisions that should be reconfirmed periodically without automatically expiring.

The system surfaces approaching expiries and due reviews so they’re not silently missed. An applicability decision past its review date is operationally still valid but flagged for reconfirmation.

Snapshot model

A change to an applicability decision creates a new audit-tracked record; the previous version remains visible in the decision history. This means an old assessment that pointed at an applicability decision continues to point at the version of the decision that existed at the time, preserving historical accuracy.

Common workflows

Recording a Statement of Applicability

Walk through the relevant framework version’s leaf nodes (typically Annex A controls).
For each one, create an applicability decision with the appropriate kind and justification.
Route to an approver; capture the methodology snapshot.
Set review dates for deferred and conditionally-applicable decisions.
Export the list when the auditor asks for the SoA.

Recording an obligation as not-applicable

Applicability → New decision. Subject is the obligation in question.
Kind: not-applicable. Justification explains the reason (no in-scope operations, exempt by virtue of size, addressed by a compensating obligation elsewhere).
Route to an approver who can defensibly make the call.
Set a review-due date so the decision is reconfirmed if conditions change.

Reconfirming a decision

From the decision, click Update. Confirm or change the kind, refresh the justification, update the methodology snapshot if applicable, route for re-approval, and reset the review-due date.
The previous decision version remains visible in the history.

Inheriting from a parent

Create the decision with kind inherited.
The justification references the parent organization’s decision.
If at some later point the local organization decides to make its own call, create a new decision with kind overridden referencing the inherited one.

Frameworks - framework nodes are common subjects.
Controls - controls have applicability decisions.
Obligations - obligations have applicability decisions.
Evidence - evidence requirements have applicability decisions.
Exceptions - waivers from an active control are recorded as exceptions, separate from applicability.