Three answers
| Answer | It means | Example |
|---|---|---|
| Yes | The objective is met: by the team's own configuration, by a central or shared control, or by a compensating control. | Sign-in is handled by the organization's single sign-on service. |
| No | The objective applies to this resource and is not met. | The application can enforce session timeouts, and they have not been turned on. |
| Not applicable | The thing the objective governs is absent from the resource. | A privacy objective, for a system that holds no personal information. |
Two common mistakes
"We don't manage that." If a central service or another team meets the objective for the resource, the answer is yes. Not applicable would hide a control the resource depends on.
"The product can't do that." If the objective applies and the product lacks the capability, the answer is no. A missing feature never excuses a control.
Not applicable belongs to the resource
Not applicable is a property of the resource, and has nothing to do with how the organization divides its work. It is correct only when the subject of the objective does not exist there: an application with no user accounts, or a system with no personal data.
Marking an objective not applicable removes it from the resource's scope. Used loosely, it makes coverage look better than it is.
What a no leads to
A no is the start of a decision. The team can close the gap, put a compensating control in place, or accept the risk and record that it has. All three keep the gap visible.
When a Team Reports a Gap describes how the security office should respond.