Main Navigation

Policy and Compliance Management

USG Policy, Standards, Procedures and Guidelines

Frequently people use the terms "policy", "standard", and "guideline" to refer to documents that fall within the policy infrastructure. So we'll use the following definitions.

A policy is typically a concise document that outlines specific requirements, business rules or company stance that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an "Appropriate Use Policy - AUP" would cover the rules and regulations for appropriate use of the computing facilities. AUP or appropriate use policy sets the rules of behavior for a business or environment.

Polices can be:

  • Program policies
  • Issue Specific polices
  • System policies

A standard is typically collections of system-specific or procedural-specific requirements that must be met by everyone. For example, you might have a standard that describes how to secure a particular type of computer for placement on the network. People must follow this standard exactly if they wish to join or connect to the network. An example would be the Minimum Security Standards for USG USO Networked Devices.

A guideline is typically a collection of system specific or procedural specific "suggestions" for best practice. They are not requirements to be met, but are strongly recommended. Effective security policies make frequent references to standards and guidelines that exist within an organization.

The policy is the organization's stance on an issue, program or system. It is a rule that everyone must meet. A standard is a requirement that supports a policy and a guideline is a document that suggests a path or guidance on how to achieve or reach compliance with a policy.

The USG follows the ACUPA Model for policy development, modified for our environment. ACUPA is an acronym for Association of College and University Policy Administrators. For more information on this model, go to www.acupa.org.

There are three phases in the USG policy development cycle: Formulate, Refine, Formalize.

In the first phase the policy directive is formulated or "put together." In the second phase, the policy directive is refined or "polished." In the third phase, the policy directive is formalized or "made official."

Formulate

  • Identify Needs
    The system CIO/CISO, the USG IT/IS community, USG staff, USG Institutions, or others may identify the need for new or revised policy directives. New legislation, audit findings, risk assessment, or strategic planning are some of the triggers that may heighten awareness of a need for policy. The need for a policy will arise in every program area.
  • Involve partners/frame issues
    Early in the process, policy developers involve system/institution stakeholders in the process. Research shows that those affected by policies or standards are more likely to comply if they have helped to frame the issues and develop the policy. Surveys may be undertaken or policy-need meetings convened. It is during this phase that the reason for and the benefits of the proposed policy are surfaced and articulated.
  • Conduct research; ensure alignment with other policies and business rules
    Research and analysis of the issues will include ensuring that proposed policies are in alignment with other policies and business rules and may include investigating higher-education best practices or policy solutions developed by other industry entities. Subject matter experts may be consulted for information and advice, like research labs. Attention should be paid to the question "What if I do not have this policy?".

Refine

  • Draft Directive
    The policy directive is drafted using a standardized and agreed format to ensure that all required elements are addressed. The standard format and development process also reinforce the view that policy directives are integrated into a cogent, coherent, and cohesive body of guidance. Policy directives reference system authority and other related policies.
  • Distribute for Review and Comment
    The draft policy is distributed for review and comment to system stakeholders and institution's stakeholders. Feedback is solicited. Depending on the complexity and scope of the policy, this may be either a formal or informal process. A policy requires a comment period sufficient for stakeholders to digest the implications of the directive and prepare comments, but not to long as to stale the process.
  • Revise
    Stakeholders revise the draft to incorporate input. All input will be considered but not necessarily incorporated. The final draft or proposed policy is given an identifier according to a numbering schema.

Formalize

  • Approve
    The Board of Regents IT Committee approves the final policy directive, and then it's on to the BOR body for final approval.
  • Release
    The release of the final policy includes a management memorandum from the CISO to the system office and the institution heads. Personnel within system and the institutions who need to know about the policy are also notified. The policy and supplementary reference materials will be accessible through the public USG InfoSec website: www.usg.edu/infosec.
  • Provide Training
    It is not enough to publish a policy. We also need to plan for training or informational sessions following the publication of a new or revised policy. The purpose of the sessions is to establish the requirements of the policy and to answer any questions affected parties have related to their compliance.
  • Implement
    The last part of the process is putting the policy into practice. It bears saying that the USG System Office must model the compliance behavior it expects from the institutions. Depending on the scope of the policy, a program of compliance monitoring may be undertaken. An additional aspect of implementation is the regular evaluation of the policy for continued usefulness.

USG Information Security Policy Development Process


The University System - Office of Information Security (OIS) web site contains links to other sites that are not owned or controlled by us. The information provided at these sites does not reflect the views of this Office or indicate an endorsement of a particular company or product. Please be aware that our Office is not responsible for the security and privacy practices of such other sites.