What are the differences between a policy a standard and a practice what type of policy would be needed to guide use of the web e-mail office equipment for personal use?

Take a look at the terms “information policies,” “information procedures,” “information standards,” and “information guidelines.” Aren’t these basically the same thing?

No, they are not and here’s why.

Policy

Policies are formal statements produced and supported by senior management. 

They can be organization-wide, issue-specific, or system-specific. Your organization’s policies should reflect your objectives for your information security program—protecting information, risk management, and infrastructure security. Your policies should be like a building foundation; built to last and resistant to change or erosion.

Standard

Standards are mandatory courses of action or rules that give formal policies support and direction.

One of the more difficult parts of writing standards for an information security program is getting a company-wide consensus on what standards need to be in place. This can be a time-consuming process but is vital to the success of your information security program.

• Used to indicate expected user behavior. For example, a consistent company email signature.
• Might specify what hardware and software solutions are available and supported.
• Compulsory and must be enforced to be effective (this also applies to policies).

Procedure

Procedures are detailed step-by-step instructions to achieve a given goal or mandate. 

They are typically intended for internal departments and should adhere to strict change control processes. Procedures can be developed as you go. If this is the route your organization chooses to take it’s necessary to have comprehensive and consistent documentation of the procedures that you are developing.

• Often act as the “cookbook” for staff to consult to accomplish a repeatable process.
• Detailed enough and yet not too difficult that only a small group (or a single person) will understand.
• Installing operating systems, performing a system backup, granting access rights to a system, and setting up new user accounts are all examples of procedures.

Guideline

Guidelines are recommendations to users when specific standards do not apply.

Guidelines are designed to streamline certain processes according to what the best practices are. Guidelines, by nature, should open to interpretation and do not need to be followed to the letter.

• Are more general vs. specific rules.
• Provide flexibility for unforeseen circumstances.
• Should NOT be confused with formal policy statements.

Final Thoughts

As you can see, there is a difference between policies, procedures, standards, and guidelines. Each has their place and fills a specific need.

Policies are the data security anchor—use the others to build upon that foundation.

Keep in mind that building an information security program doesn’t happen overnight. It is a conscious, organization-wide, process that requires input from all levels. Building your program is not just up to the IT department; that’s where most of the issues come up.

Everyone needs to be on board.

Getting organization-wide agreement on policies, standards, procedures, and guidelines is further complicated by the day-to-day activities that need to go in order to run your business.

In the end, all of the time and effort that goes into developing your security measures within your program is worth it. Building a comprehensive information security program forces alignment between your business objectives and your security objectives and builds in controls to ensure that these objectives, which can sometimes be viewed as hindrances to one another, grow and succeed as one.

If you need help building your information security program—regardless of if it’s from square one or just to make top-end improvements—reach out to us at frsecure.com.

Course Hero uses AI to attempt to automatically extract content from documents to surface to you and others so you can study better, e.g., in search results, to enrich docs, and more. This preview shows page 3 - 5 out of 6 pages.

When it comes to cybersecurity compliance, words have specific meaning and it is important to get those terms correct. In reality, these cybersecurity documentation 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.  Cybersecurity, IT professionals, privacy and legal professionals routinely abuse the terms “policy” and “standard” as if these words were synonymous, when they are not! ComplianceForge compiled the information on this page to help get everyone on the same sheet of music, since documentation terminology is important as these words have specific meanings as they pertain to cybersecurity and privacy requirements.  Cybersecurity & data protection documentation needs to usable – it cannot just exist in isolation. This means the documentation needs to be written clearly, concisely and in a business-context language that users can understand. By doing so, users will be able to find the information they are looking for and that will lead to cybersecurity and privacy "best practices" being implemented throughout your organization. Additionally, having clearly-written and concise documentation can be “half the battle” when preparing for an audit, since it shows that effort went into the program and key requirements can be easily found.

Click here for a free guide

In the context of good cybersecurity & privacy documentation, policies, standards and procedures are key components that are intended to be hierarchical and build on each other to build a strong governance structure that utilizes an integrated approach to managing requirements. Your cybersecurity & data protection documentation is meant to address the “who, what, when, how & why” across the strategic, operational and tactical needs of your organization:

A common question is “What is the difference between a policy vs a standard?”

In simple terms, a policy is a high-level statement of management intent that formally establishes requirements to guide decisions and achieve rational outcomes. A policy is intended to come from the CEO or board of directors that has strategic implications. However, a standard is a formally-established requirement in regard to a process, action or configuration that is meant to be an objective, quantifiable expectation to be met (e.g., 8 character password, change passwords every 90 days, etc.).

In reality, no one should ever ask for an exception to a policy. Exceptions should only be for standards when there is a legitimate business reason or technical limitation that precludes a standard from being followed (e.g., vulnerability scanning exception for a "fragile" application that breaks when scanned by the default scanning profile). It is important that if a standard is granted an exception, there should be a compensating control placed to reduce that increased risk from the lack of the required standard (e.g., segment off the application that cannot be scanned for vulnerabilities).

If you visualize these concepts, you can see the hierarchical nature of these documentation components, where policies are the foundation that everything builds upon:

Documentation Should Be Hierarchical: Policy > Standard > Procedure

In an effort to help clarify this concept, ComplianceForge Hierarchical Cybersecurity Governance Framework™ (HCGF) takes a comprehensive view towards the necessary documentation components that are key to being able to demonstrate evidence of due diligence and due care. This framework addresses the interconnectivity of policies, control objectives, standards, guidelines, controls, risks, procedures & metrics. The Secure Controls Framework (SCF) fits into this model by providing the necessary cybersecurity and privacy controls an organization needs to implement to stay both secure and compliant.

ComplianceForge has simplified the concept of the hierarchical nature of cybersecurity and privacy documentation in the following downloadable diagram to demonstrate the unique nature of these components, as well as the dependencies that exist:

Assigning "Ownership" of Policies, Standards and Procedures

One of the most important things to keep in mind with procedures is that the "ownership" is different than that of policies and standards:

• Policies, standards and controls are designed to be centrally-managed at the corporate level (e.g., governance, risk & compliance team, CISO, etc.)
• Controls are assigned to stakeholders, based on applicable statutory, regulatory and contractual obligations
• Procedures are by their very nature de-centralized, where control implementation at the control level is defined to explain how the control is addressed. 

Given this approach to how documentation is structured, based on "ownership" of the documentation components:

• Policies, standards and controls are expected to be published for anyone within the organization to have access to, since it applies organization-wide. This may be centrally-managed by a GRC/IRM platform or published as a PDF on a file share, since they are relatively static with infrequent changes.
• Procedures are "living documents" that require frequent updates based on changes to technologies and staffing. Procedures are often documented in "team share" repositories, such as a wiki, SharePoint page, workflow management tool, etc.

Why Should You Care About Policy vs Standard vs Control vs Procedure?

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, as 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. Protecting the data and the systems that collect, process and maintain this data is of critical importance. Commensurate with risk, security and privacy measures must be implemented to guard against unauthorized access to, alteration, disclosure or destruction of data and systems, applications and services. This also includes protection against accidental loss or destruction. The security of systems, applications and services must include controls and safeguards to offset possible threats, as well as controls to ensure confidentiality, integrity, availability and safety:

CONFIDENTIALITY – Confidentiality addresses preserving restrictions on information access and disclosure so that access is limited to only authorized users and services. INTEGRITY – Integrity addresses the concern that sensitive data has not been modified or deleted in an unauthorized and undetected manner. AVAILABILITY – Availability addresses ensuring timely and reliable access to and use of information. SAFETY – Safety addresses reducing risk associated with embedded technologies that could fail or be manipulated by nefarious actors.

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, as 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 nauseum 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. 

Well-designed documentation is comprised of five (5) core components:

• Policies are established by an organization’s corporate leadership establishes “management’s intent” for cybersecurity and data protection requirements that are necessary to support the organization’s overall strategy and mission.
• Control Objectives identify the technical, administrative and physical protections that are generally tied to a law, regulation, industry framework or contractual obligation.
• Standards provide organization-specific, quantifiable requirements for cybersecurity and data protection.
• Guidelines are additional guidance that is recommended, but not mandatory.
• Procedures (also known as Control Activities) establish the defined practices or steps that are performed to meet to implement standards and satisfy controls / control objectives.

External Framework Frameworks are often referred to as a standard. In reality, most frameworks are merely a repository of specific controls that are organized by control families (e.g., NIST CSF, ISO 27002, NIST SP 800-171, NIST SP 800-53, etc.). For example, while NIST SP 800-53 R5 is called a "standard" it is made up of 1,189 controls that are organized into 20 control families (e.g., Access Control (AC), Program Management (PM), etc.). These controls are what make up NIST SP 800-53 as a "framework" that an organization can use as a guide to develop its internal policies and standards that allow it to align with those expected practices.

Internal Security Documentation An organization is expected to identify a framework that it wants to align its cybersecurity program with, so that its practices follow reasonably-expected controls. Ideally, there should be a policy that corresponds to each of the control families. This helps make an organization's alignment with its adopted framework more straightforward. Control objectives provide a 1-1 mapping to address a specific control (e.g., AC-3, AC-7, etc.). For each control objective: There should be a granular standard that addresses the objective of the control (hence the name "control objective"). The standard may or may not have guidelines that accompany the standard. There should be a Standardized Operating Procedure (SOP) that describes how the standard is operationalized to meet the intent of the control.

Understanding Basic Cybersecurity & Data Protection Documentation Components

Since words have meanings, it is important to provide examples from industry-recognized sources for the proper use of these terms that make up cybersecurity & privacy documentation:

Policy

Policies are high-level statements of management intent from an organization’s executive leadership that are designed to influence decisions and guide the organization to achieve the desired outcomes. Policies are enforced by standards and further implemented by procedures to establish actionable and accountable requirements. Policies are a business decision, not a technical one. Technology determines how policies are implemented. Policies usually exist to satisfy an external requirement (e.g., law, regulation and/or contract).

• ISACA Glossary:
• A document that records a high-level principle or course of action that has been decided on.
• The intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.
• Overall intention and direction as formally expressed by management.
• ISO 704:2009:
• Any general statement of direction and purpose designed to promote the coordinated planning, practical acquisition, effective development, governance, security practices, or efficient use of information technology resources.
• ISO 27000:2016:
• Intention and direction of an organization as formally expressed by its top management.
• NIST Glossary:
• Statements, rules or assertions that specify the correct or expected behavior of an entity.
• A statement of objectives, rules, practices or regulations governing the activities of people within a certain context.
• NIST Glossary (Security Policy):
• Security policies define the objectives and constraints for the security program. Policies are created at several levels, ranging from organization or corporate policy to specific operational constraints (e.g., remote access). In general, policies provide answers to the questions “what” and “why” without dealing with “how.” Policies are normally stated in terms that are technology-independent.
• A set of rules that governs all aspects of security-relevant system and system element behavior.
• Note 1: System elements include technology, machine, and human, elements.
• Note 2: Rules can be stated at very high levels (e.g., an organizational policy defines acceptable behavior of employees in performing their mission/business functions) or at very low levels (e.g., an operating system policy that defines acceptable behavior of executing processes and use of resources by those processes).

Control Objective

Control Objectives are targets or desired conditions to be met. These are statements describing what is to be achieved as a result of the organization implementing a control, which is what a Standard is intended to address. Where applicable, Control Objectives are directly linked to an industry-recognized secure practice to align cybersecurity and privacy with accepted practices. The intent is to establish sufficient evidence of due diligence and due care to withstand scrutiny.

• ISACA Glossary:
• A statement of the desired result or purpose to be achieved by implementing control procedures in a particular process.
• ISO 27000:2016:
• Statement describing what is to be achieved as a result of implementing controls.

Standard

Standards are mandatory requirements regarding processes, actions and configurations that are designed to satisfy Control Objectives. Standards are intended to be granular and prescriptive to ensure systems, applications and processes are designed and operated to include appropriate cybersecurity and privacy protections.

• ISACA Glossary:
• NIST Glossary:
• A published statement on a topic specifying the characteristics, usually measurable, that must be satisfied or achieved to comply with the standard.
• A rule, condition, or requirement describing the following information for products, systems, services or practices:
• Classification of components.
• Specification of materials, performance, or operations; or
• Delineation of procedures. 

Guideline / Supplemental Guidance

Guidelines are recommended practices that are based on industry-recognized secure practices. Guidelines help augment Standards when discretion is permissible. Unlike Standards, Guidelines allow users to apply discretion or leeway in their interpretation, implementation, or use.

• ISACA Glossary:
• A description of a particular way of accomplishing something that is less prescriptive than a procedure.
• ISO 704:2009:
• Recommendations suggesting, but not requiring, practices that produce similar, but not identical, results.
• A documented recommendation of how an organization should implement something.
• NIST Glossary:
• Statements used to provide additional explanatory information for security controls or security control enhancements.

Control

Controls are technical, administrative or physical safeguards. Controls are the nexus used to manage risks through preventing, detecting or lessening the ability of a particular threat from negatively impacting business processes. Controls directly map to standards, since control testing is designed to measure specific aspects of how standards are actually implemented.

• ISACA Glossary:
• The means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.
• ISO 27000:2016:
• The policies, procedures, practices and organizational structures designed to provide reasonable assurance that business objectives will be achieved and undesired events will be prevented or detected and corrected.
• Measure that is modifying risk:
• Controls include any process, policy, device, practice, or other actions which modify risk.
• Controls may not always exert the intended or assumed modifying effect.
• NIST Glossary:
• Measure that is modifying risk. (Note: controls include any process, policy, device, practice, or other actions which modify risk.)
• NIST SP 800-53 R5:
• The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information [security control].
• The administrative, technical, and physical safeguards employed within an agency to ensure compliance with applicable privacy requirements and manage privacy risks [privacy control].

Procedure

Procedures are a documented set of steps necessary to perform a specific task or process in conformance with an applicable standard. Procedures help address the question of how the organization actually operationalizes a policy, standard or control. Without documented procedures, there can be defendable evidence of due care practices. Procedures are generally the responsibility of the process owner / asset custodian to build and maintain but are expected to include stakeholder oversight to ensure applicable compliance requirements are addressed. The result of a procedure is intended to satisfy a specific control. Procedures are also commonly referred to as “control activities.”

• ISACA Glossary:
• A document containing a detailed description of the steps necessary to perform specific operations in conformance with applicable standards. Procedures are defined as part of processes.
• ISO 704:2009:
• A detailed description of the steps necessary to perform specific operations in conformance with applicable standards.
• A group of instructions in a program designed to perform a specific set of operations.
• NIST Glossary:
• A set of instructions used to describe a process or procedure that performs an explicit operation or explicit reaction to a given event.

Risk

Risks represents a potential exposure to harm or loss. Risk is often calculated by a formula of Threat x Vulnerability x Consequence in an attempt to quantify the potential magnitude of a risk instance occurring. While it is not possible to have a totally risk-free environment, it may be possible to manage risks by avoiding, reducing, transferring, or accepting the risks.

• ISACA Glossary:
• The combination of the probability of an event and its consequence.
• ISO 704:2009:
• The level of impact on organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation resulting from the operation of an information system given the potential impact of a threat and the likelihood of that threat occurring.
• NIST SP 800-53 R5:
• A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of:
• The adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and
• The likelihood of occurrence.
• NIST Glossary:
• A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of:
• The adverse impacts that would arise if the circumstance or event occurs; and
• The likelihood of occurrence. Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.

Metric

Metrics provide a “point in time” view of specific, discrete measurements, unlike trending and analytics that are derived by comparing a baseline of two or more measurements taken over a period of time. Analytics are generated from the analysis of metrics. Analytics are designed to facilitate decision-making, evaluate performance and improve accountability through the collection, analysis and reporting of relevant performance related data. Good metrics are those that are SMART (Specific, Measurable, Attainable, Repeatable, and Time-dependent)

• ISACA Glossary:
• A quantifiable entity that allows the measurement of the achievement of a process goal.
• ISO 704:2009:
• A thing that is measured and reported to help with the management of processes, services, or activities.
• NIST Glossary:
• Tools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data.

Questions? Please contact us for clarification so that we can help you find the right solution for your cybersecurity and privacy compliance needs.