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.
Guidelines. 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.