Blog

Understanding Policies, Control Objectives, Standards, Guidelines & Procedures

Posted by

Cybersecurity terminology is important. Cybersecurity, IT professionals and legal professionals routinely abuse the terms “policy” and “standard” as if these words are synonymous. In reality, these terms have quite different implications and those differences should be kept in mind, since the use of improper terminology has cascading effects that can negatively impact the internal controls of an organization.

According to ISACA, “internal controls” include the policies, standards, procedures and other organizational structures that are designed to provide reasonable assurance that business objectives will be achieved and undesired events will be prevented, detected and corrected. Essentially, governance over these controls is the power to influence or direct people's behavior or the course of events.

Why Should You Care?

Governance is built on words. Beyond just using terminology properly, understanding the meaning of these concepts is crucial in being able to properly implement cybersecurity and privacy governance within an organization. An indicator of a well-run governance program is the implementation of hierarchical documentation, since it involves bringing together the right individuals to provide appropriate direction, based on the scope of their job function.

To help visualize that concept, imagine the board of directors of your organization publishing procedural process guidance for how a security analyst performs daily log review activities. Most would agree that such a scenario is absurd, since the board of directors should be focused on the strategic direction of the company and not day-to-day procedures.

However, in many organizations, the inverse occurs where the task of publishing the entire range of cybersecurity documentation is delegated down to individuals who might be competent technicians, but do not have insights into the strategic direction of the organization. This is where the concept of hierarchical documentation is vitally important, since there are strategic, operational and tactical documentation components that have to be addressed to support governance functions.

Understanding the hierarchy of cybersecurity documentation can lead to well-informed risk decisions, which influence technology purchases, staffing resources and management involvement. That is why it serves both cybersecurity and IT professionals well to understand the cybersecurity governance landscape for their benefit, since it is relatively easy to present issues of non-compliance in a compelling business context to get the resources you need to do your job.

What Wrong Looks Like

All too often, documentation is not scoped properly and this leads to the governance function being more of an obstacle, as compared to an asset. A multiple-page “policy” document that blends high-level security concepts (e.g., policies), configuration requirements (e.g., standards) and work assignments (e.g., procedures) is an example of poor governance documentation that leads to confusion and inefficiencies across technology, cybersecurity and privacy operations. Several reasons why this form of documentation is considered poorly-architected documentation include:

  • Human nature is always the mortal enemy of unclear documentation, since people will not take the time to read it. An ignorant or ill-informed workforce entirely defeats the premise of having the documentation in the first place.
  • If the goal is to be “audit ready” with documentation, having excessively-wordy documentation is misguided. Excessive prose that explains concepts ad nausea in paragraph after paragraph makes it very hard to understand the exact requirements and that can lead to gaps in compliance.

What Right Looks Like

In the context of good cybersecurity documentation, these components are hierarchical and build on each other to build a strong governance structure that utilizes an integrated approach to managing requirements:

  • Policy. A policy is high-level statement of management intent that formally establishes requirements to guide decisions and achieve rational outcomes.
    • Essentially, a policy is a statement of expectation, that is enforced by standards and further implemented by procedures.
    • External influencers, such as statutory, regulatory or contractual obligations, are commonly the root cause for a policy’s existence.
  • Control Objective. Control Objectives are targets or desired conditions to be met that are designed to ensure that policy intent is met.
    • Control Objectives help to establish the scope necessary to address a policy.
    • Where applicable, Control Objectives should be directly linked to an industry-recognized practice (e.g., statutory, regulatory or contractual requirements).
  • Standard. Standards are formally-established requirements in regard to processes, actions, and configurations.
    • Standards are finite, quantifiable requirements that satisfy Control Objectives.
    • Exceptions are always to Standards and never to Policies. If a standard cannot be met, it is generally necessary to implement a compensating control to mitigate the risk associated with that deficiency.
  • Guideline. Unlike Standards, Guidelines allow users to apply discretion or leeway in their interpretation, implementation, or use.
    • Guidelines are generally recommended practices that are based on industry-recognized practices or cultural norms within an organization.
    • Guidelines help augment Standards when discretion is permissible.
  • Procedure. Procedures are a formal method of doing something, based on a series of actions conducted in a certain order or manner.
    • Procedures are the responsibility of the asset custodian to build and maintain, in support of standards and policies.

A picture is sometimes worth a 1,000 words – this concept can be seen here in a swim lane diagram that.

​NIST 800-171 for Federal Contractors (FAR)

NIST 800-171 isn’t just for Department of Defense (DoD) contractors. Representatives from the National Institute of Standards and Technology (NIST) and DoD officials have recently been putting this information out in webinars and other training seminars on NIST 800-171. In summary, all US government contractors will have to comply with the NIST 800-171 requirements. This is [...]

Read More »

Multi-Factor Authentication (MFA) for NIST 800-171 Compliance - Requirement #3.5.3

One of the most common technical questions we receive is about implementing Multi-Factor Authentication (MFA) as part of NIST 800-171 compliance (requirement #3.5.3 - Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts).When you cut through the hype for MFA products, there are generally two ways to incorporate [...]

Read More »

Cybersecurity & Privacy Compliance - Statutory vs Regulatory vs Contractual Obligations

Compliance terms are pretty badly abused, even by professionals within the cybersecurity and privacy industries. This is our attempt to help get everyone on the same sheet of music, since words do have meanings and it is important to understand cybersecurity and privacy requirements.STATUTORY CYBERSECURITY & PRIVACY REQUIREMENTS Statutory obligations are required by law and refer [...]

Read More »

Searching For A Magic Pill?

A little commentary on cybersecurity compliance from a cybersecurity professional During a recent commercial break on the news, there were several advertisements for new pharmaceuticals that addressed everything from lowering blood pressure to diabetes. The one thing that each commercial had in common was that each drug still required healthy eating and exercise to be effective. [...]

Read More »

Tick, Tock on NIST 800-171 Compliance

If you have contracts with the US Department of Defense (DoD) or are a subcontractor to a prime contractor with DoD contracts, your organization has until December 31, 2017 to implement NIST SP 800-171 . This is a requirement that is stipulated in the Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012. In the context of this article, DFARS focuses on two things: Safeguarding Covered [...]

Read More »

The new baseline for private industry - NIST 800-171 Appendix E - Non-Federal Organization (NFO) Controls

Non-Federal Organization (NFO) controls are "expected to be routinely satisfied by non-federal organizations without specification." This is an often-overlooked reference from Appendix E of NIST 800-171.In this context, the term "without specification" means that the National Institute of Standards and Technology (NIST) feels the requirements do not need a detailed description of the requirements, due to the requirement being basic. [...]

Read More »

NIST 800-171 Compliance Video

We put a video together for businesses that need to comply with NIST 800-171, but do not know where to start. It covers how to define Controlled Unclassified Information (CUI), as well as Appendix D and Appendix E from NIST 800-171.ComplianceForge YouTube Channel: NIST 800-171 Compliance Video - https://youtu.be/aSLfCnV_frU 

Read More »

DFARS 252.204-7012 / NIST 800-171 Requirements - Non-Federal Organizations (NFO)

Have You Looked At Appendix E of NIST 800-171?While it is not called out with the main NIST 800-171 requirements in chapter 3, Appendix E contains numerous NIST 800-53 controls that are marked as Non-Federal Organizations (NFO). Essentially, these NFO requirements are "expected to be routinely satisfied" by government contractors without NIST 800-171 having to [...]

Read More »

​Scoping NIST 800-171 - Use PCI DSS As A Guide

Managing NIST 800-171 Scoping If you are new to NIST 800-171, it is intended to help "non-federal entities" (e.g., contractors) to comply with new security requirements using the systems and practices that contractors already have in place, rather than trying to use government-specific approaches. It also provides a standardized and uniform set of requirements for all [...]

Read More »

Sign up for our Newsletter!

×
×