Skip to content Skip to main navigation Report an accessibility issue
Information Security

Context is Everything! 



One definition of context is the circumstances that form the setting for an event, statement, or idea and in terms of which it can be fully understood and assessed. It isalso one of the reasons that every cyber security professional respond with, “…it depends” when asked about a control in a security plan.

UT Policy requires each campus to base its security methodology on the National Institute of Standards and Technology (NIST) framework. At UT Knoxville, all the requirements in a security plan originate from NIST. While NIST requirements (aka controls) are written with a government agency audience in mind, the controls apply to any system, given the correct CONTEXT. (Yes, you will see that word again.)

A response is a system owner’s explanation of how a given NIST control is applied IN THE CONTEXT OF THE SYSTEM thatthey’reassessing as opposed to the context of the campus or any other system or plan.

Two important examples of context to keep in mind are the NIST controls AT-2 (Security Awareness Training) and AT-3 (Role-Based Security Training). It is perfectly acceptable to interpret AT-2 controls in the context of the general annual Security Awareness Training assigned to all faculty and staff. However, AT-3 addresses training specific to the information system being assessed. The control is “asking” if role-based training is required “before authorizing access to the information system or performing assigned duties.” The AT-3 context is THE SYSTEM as opposed to the campus. For example, based on the system being described, are administrators required to complete any security training specific to their role or duties before gaining access to the system? The control is not “asking” if the campus requires role-based training.

NIST controls and language, while not difficult to read, can be confusing when the incorrect context is assumed. ALWAYS look at the requirement in the context of the system that’s being described. In the context of a SYSTEM security plan, the phrase “the organization” is used frequently, and the intended context is the group (i.e., department, college, team, etc.) responsible for the system described in the plan.

What’s appropriate in one context is not always appropriate in another context. When formulating a response to a NIST control, ask yourself, “What is the context of the question?” If the definition indicates that the control is described in the context of the system being described, answer in the context of THAT system.

One of the values around documenting controls for systems is that it causes a system owner to think in contextual terms. Sometimes the answer is, “This control is NOT appropriate or necessary for this environment,” or “NO role-based training is currently available for this system.” In either case, the control is NOT implemented, and based on your evaluation of the control; you deem it NOT applicable to the system you support. Keep in mind that an auditor or assessor may disagree, recommend additional controls, or ask for your written justification. However, no one will fault you for non-disclosure. As a system owner, consider the control, the IT risks associated with NOT applying a control, and document your response.

If you have questions regarding system security plans, don’t assume; ask. Contact the OIT HelpDesk at 865-974-9900, and a security professional will contact you.