What are Cybersecurity Policies?
Cybersecurity Policies are a formal set of rules issued by an organization to ensure all authorized users of information technology resources and assets comply with rules and guidelines. Security Policies can provide additional benefits to an organization as well:
- Allows for policy consistency across an organization. Policies should be clear, concise, and leave no room for interpretation.
- Details and upholds discipline and accountability. Policies should inform users about their responsibilities related to what they can and cannot do while using an organizations technology resources and assets. They should also outline the disciplinary actions for violating policy.
- Helps to educate users on security.
If policies set the rules and expectation for use of information technology resources and assets, then what are Security Standards?
Security Standards provide the methods, guidelines, references to frameworks to ensure efficiency. They establish a common language, and contain technical specification or other criteria, with the goal being to improve the security of information technology.
When do new policies come into enforcement?
Policies are considered living documents and should be reviewed annually, at the very least. This allows Information Technology staff and other stakeholders an opportunity to update documentation when necessary. There should always be an announcement to vested parties when a new policy is being published or an existing policy has been revised, which should include details – e.g., where to locate the policy, date it comes into enforcement.
What if our current processes are not in compliance, or we expect a process will not be compliant with a new policy?
While we ask all business units to make reasonable efforts to comply with policies and standards, we understand there are situations where 100% compliance may not be possible. If your group has a process or system which cannot comply with ̾Ƶ policies or standards, we ask you contact the Cybersecurity GRC group assist with an exception.
We need an exception. How do we start the process?
You can email the Cybersecurity GRC group at Cybersecurity.GRC@usnh.edu or submit a ticket via TeamDynamix
We have an exception, now what?
Exceptions are not meant to be a set and forget solution. Rather, the exceptions should be reviewed annually to determine if updates are required as often times processes and systems can change.
Who can we contact for more information regarding policies, standards, exceptions, or simply to ask a question?
Please reach out to Cybersecurity.GRC@usnh.edu with any questions you may have.
What is a Security Review?
The Security Assessment Review (SAR) process, administered by Cybersecurity Governance, Risk, and Compliance (GRC), is required whenever institutional information classified as anything other than Public will be captured, stored, processed, transmitted, or otherwise managed by a third party (e.g., vendor, service provider). Reviews can also be performed if requested by the relevant data steward, Service Line Leaders (SLL), Chief Information Security Officer (CISO) or the Chief Information Officer (CIO).
Information classification types are identified in the ̾Ƶ Information Classification Policy.
Why is a Security Review necessary?
When ̾Ƶ information is captured or stored in non-̾Ƶ information technology resources, stored in non-̾Ƶ facilities, or handled by non-̾Ƶ persons, it is subjected to unknown risks. Those who are responsible for appropriate handling of such information must understand what type of information is involved, what level of protection it requires, what the risks are to the information, and how those risks will be mitigated.
The USNH Security Assessment Review (SAR) process assists in the identification of the risks associated with information being placed into non-̾Ƶ information technology resources or handled by non-̾Ƶ persons. The key factor used to assess risk in these circumstances is the institutional information that will be captured, stored, processed, transmitted, or otherwise managed by a third-party.
What Documentation is needed from the vendor?
̾Ƶ uses the HECVAT (Higher Education Community Vendor Assessment Tool) developed and maintained by Educause as the basis of its security assessment review program.Often, we work with vendors who engage with other higher education institutions and may have previously completed the HECVAT, which we will accept if it is a recent version - v2.10, v2.11, or v3.0. More information can be found on the .
We will also accept a SOC 2 Type 2 Report in lieu of the HECVAT. A SOC 2 Type 2 report is an assessment of a company’s safeguards and controls used to protect customer data over a given time frame performed by a third-party.
We may also request the vendor provide additionaldocumentationto assist with our review; includingbut not limited to:
- Information Security Policy
- Disaster Recovery Plan
- Business Continuity Plan
- Privacy Policy
- Terms and Conditions
What determines which HECVAT the vendor should complete?
There are two versions of the HECVAT – the HECVAT Full and the HECVAT Lite. Any third-party product that will capture, store, process, transmit, or otherwise manage RESTRICTED information must complete the HECVAT Full. Simple engagements and LTIs that will integrate into Canvas can use the HECVAT Lite as long as there is no financial transaction processing.
Whenshould the documentation be obtained from the vendor?
As early in the procurement/implementation process as possible. However, we do understand vendors may not provide this information to the institution prior to a contract or agreement being in place. If there is a contract or agreement, we would request an opportunity to review any language pertaining to information security. Upon reviewing the contract, we reserve the right to request the addition of the ̾Ƶ Data Security Addendum if we determine it is within the best interest of ̾Ƶ.
How can I request a Security Assessment Review?
You can request a review by submitting a ticket - .
The requested documentation has been submitted for a review. What happens next?
Once we receive a completed HECVAT and the supplement, we will begin our review. During this time we will identify any concerns, questions which may need more information or clarification, or the need for additional documentation from the vendor. Once our initial review has been completed, we will provide feedback to the business unit which may include requests for more information, if necessary.
Who should I contact if we have questions regarding a Security Review?
If there are questions regarding a Security Review, please contact:
- Kelly Sweeney- Cybersecurity GRC Analyst
- Tomi Gibson - Cybersecurity GRC Analyst
- Dr. David Yasenchock - Director, IT Governance, Risk, and Compliance
- Tom Nudd - CISO
- Cybersecurity.GRC@usnh.edu
Enterprise Technology & Services (ET&S) recognizes that there are timeswhen business needs, academic activities, and/or research project requirements make it impossible or impractical to comply withthe established Technology/Cybersecurity Policies & Standards and understands that there are circumstances where exceptions must be allowed.
Exceptions are temporary exemptions from Policy or Standard compliance.
Some examples of exceptions are:
- Use of software that requires a device running on old operating system
- Processes involving community members or administrators sharing accounts
- Servers or other information technology resources with vulnerabilities that cannot be fixed because of extenuating circumstances
- Business processes that cannot meet requirements because of resource constraints
The exception process, defined in theCybersecurity Exception Standard, provides members of the ̾Ƶ community with a single point of contact to request exceptions to all Technology/Cybersecurity Policies & Standards. Requiring documented exceptions enables Cybersecurity & Networking to better manage cybersecurity risk across all ̾Ƶ institutions.
To request an exception, submit a ticket via TeamDynamix and provide as much of the information below as possible:
- The Policy or Standard for which the exception is being requested
- Business reason or justification explaining why anexception is needed
- Administrative, academic, or business unit requesting the exception
- Head of the requesting unit
- Describe why compliance is not possible (e.g. the total cost to comply with the Policy or Standard or the negative impact to ̾Ƶ community members including an estimate of the number of community members that may be negatively impacted)
- List of the business units, business processes, information technology resources, and institutional information to which the exception applies
- How long will the exception be needed
Requests for exceptions are handled by Cybersecurity Governance, Risk, & Compliance (GRC). When a request is submitted, a ticket is created which allows the requester to view the status of the request and communicate directly with the Cybersecurity GRC team in the.
Submit an exception request ticket via the
The ticket will include fields highlighted in the̾Ƶ Risk Exception Form(downloads word document ). Please provide as much information as possible. If you have any questions, contact Cybersecurity GRC.
Ever have one of your emails get reported to IT as a Phishing attempt? Microsoft incorrectly tag your email as Spam? This document provides tips on how to draft an email you can feel confident about sending to coworkers.
How to Prevent Your Emails from Being Reported as Spam or Phishing
Enterprise Technology & Services (ET&S) places significant value on our ability to establish and maintain a trusted relationship with the ̾Ƶ community. In order to maintain that trust, it is essential that all ET&S employees, sponsored users, and student workers understand their responsibilities in relation to maintaining the confidentiality, integrity, and availability of ̾Ƶ (̾Ƶ) institutional information and information technology resources and protecting the privacy of each individual community member.
The purpose of this agreement is to codify the responsibilities of all ET&S employees, sponsored users, and student workers for maintaining the confidentiality, integrity, availability, and privacy of institutional information and information technology resources. The following agreement is between you and ̾Ƶ, on behalf of its component institutions.
The full agreement can be reviewed here - ̾Ƶ ET&S Confidentiality Agreement
The Higher Education Compliance Alliance has a Compliance Matrix that lists key federal laws and regulations governing colleges and universities. The matrix can be used for general guidance and is a tool to help understand different regulatory requirements.
HIPAA information is classified as Restricted information at ̾Ƶ (review the ̾Ƶ Information Classification Policyfor more information on classifications).Sharepoint and Teams can store this type of data when properly configured.If you require a HIPAA compliant Sharepoint or Teams location,t to the Office 365 team.
NEVER store Restricted information on Sharepoint or Teams without first consulting the Office 365 Team.
Additional information on .
̾Ƶ, Zoom, and HIPAA compliance -The ̾Ƶ has entered into a Business Associate Agreement with Zoom Video Communications for use of their Zoom web conferencing platform for healthcare-related needs under HIPAA. Zoom provides a secure, encrypted communications platform for all uses. The BAA allows for ̾Ƶ to use Zoom in ways that meet the specific requirements that exist for handing of electronic healthcarerecords.
For individuals or departments with HIPAA approved Zoom account - All recording functions will be disabled and locked. Users will not be able to use Zoom for any recording purposes. This will apply to all meetings setup by anyone with a HIPAA compliant Zoom account.Neveruse Kaltura or other tools to record Zoom meetings where HIPAA information is present.
Questions? Contact Cybersecurity.GRC@usnh.edu
How to register for the ̾Ƶ Cybersecurity Training
- To access the ̾Ƶ Online Learning Center, go to the.
- Access your course Catalog by clicking on the blue Catalog box on the right side of the screen.
- Search for courses in the top right-hand corner of the catalog by using the “search catalog” function.
- Search for the ̾Ƶ Cybersecurity course by:
Course ID: CS1
OR
Title: ̾Ƶ Cybersecurity Fundamentals
- Click on the Course ID or Title to be taken to the main course page.
- Click on the orange “Take Course” button in the top right-hand corner to begin the training.
Protection of Common Data Elements
University data is often characterized by category or use of the data and then classified in accordance with the legal or contractual controls placed on it. However, data elements within compliance programs often warrant different levels of protection. While some data elements offer little risk and require no special protection, inappropriate handling of other data elements might result in criminal or civil penalties, identity theft, and/or personal or organizational loss.
This table identifies some common data elements by category and the associated classification. These categories are subjectto change based on University polices, guidelines and changes to local, state, or federal law.When using this table consider:
-
Not all data elements are listed. Absence of a data element does not mean that it requires no protection.
-
Quantity/amount of data must be considered. One thousand records of one data element may have more value together than one record of an element with a seemingly higher protection factor.
-
Combination of data elements can increase the value. For example, The Family Educational Rights and Privacy Act (FERPA) identifies Personally Identifiable Information (PII) as information that can identify a person even though the name may not be given.
Personnel Information (Human Resources)
|
Personnel Information Elements |
Information Classification |
|
Social Security Number (SSN) |
Restricted – NH Data Privacy Act (when combined with a name or other uniquely identifiable personal information). |
|
Driver’s License number |
Restricted – NH Data Privacy Act (when combined with a name or other uniquely identifiable personal information). |
|
State Identification Number |
Restricted – NH Data Privacy Act (when combined with a name or other uniquely identifiable personal information). |
|
Genetic Information |
Restricted – Genetic Information Nondiscrimination Act (GINA). Information must be safeguarded as health information in accordance with The Health Insurance Portability and Accountability Act of 1996 (HIPAA). |
|
Disability Status |
Restricted |
|
Military Disability |
Restricted |
|
Status Ethnicity/Race |
Protected |
|
Gender Status |
Protected |
|
Name |
Public |
|
Date of Birth (DOB) |
Protected |
|
Employee Identification Number (EMPLID) |
Sensitive – An EMPLID is not considered Restricted or Protected Data and is not afforded special protection. EMPLIDs uniquely identify staff and faculty members without using Restricted Data such as SSNs. Routine shared use of EMPLIDs is sometimes necessary for university functions. Share EMPLIDs only with those who have a reason to use them. Combinations of information increase the value of data. EMPLIDs when used in combination with name or DOB increase the security risk. |
|
Home Address |
Protected – Not releasable by State Statute. |
|
Home Phone Number |
Protected – Not releasable by State Statute. |
|
Work Address |
Public – Not protected by any legal or contractual controls. |
|
Work Phone Number |
Public – Not protected by any legal or contractual controls. |
|
Business Email Address |
Public – Not protected by any legal or contractual controls. |
Payroll Information
|
Payroll Information Elements |
Information Classification |
|
Social Security Number Bank Information (routing/account numbers) |
Restricted – NH Data Privacy Act and Gramm-Leach-Bliley Act (GLBA) |
|
Salaries |
Not Protected – Not protected and is public only through official channels. |
|
Work Study Awards |
Sensitive – Protect this information as it is indicative of financial need. Some work study is non-need based and does not require protection. |
|
Employee Verification (i.e., salaries) |
Not Protected – Human Resources (HR) will only verify what the Bank or Third Party was told by employee |
Protected Health Information (PHI)
|
Protected Health Information (PHI) Elements |
Information Classification |
|
Past, present, or future physical or mental health or condition of an individual. |
Restricted – HIPAA – If the information identifies or provides a reasonable basis to believe it can be used to identify an individual, it is considered individually identifiable health information. The HIPAA privacy rule lists 18 identifiers that are not to be used with a health record. |
|
Provision of health care to an individual. Includes past, present, or future payment for the provision of health care to an individual. |
Restricted – HIPAA – If the information identifies or provides a reasonable basis to believe it can be used to identify an individual, it is considered individually identifiable health information. The HIPAA privacy rule lists 18 identifiers that are not to be used with a health record. |
|
Identifiers – 18 specific identifiers by HIPAA Privacy Rule (includes such information as name, geographic information, dates, contact information, medical record and account numbers, biometric identifiers, photos, and other uniquely identifying number, characteristic or code) |
Restricted – HIPAA – Those working with protected health information need to be familiar with the identifiers as listed by the HIPAA Privacy Rule and protect them accordingly. These identifiers by themselves may not be restricted data, but when associated in any way with the Personal Health Information elements listed above, they are restricted under HIPAA. |
Student Data (Registrar)
|
Student Data Elements |
Information Classification |
|
Social Security Number (including historical student identification number when it was SSN) |
Restricted – NH Data Privacy Act & FERPA (When combined with a name or other uniquely identifiable personal information). |
|
Driver’s License Number |
Restricted – NH Data Privacy Act & FERPA (When combined with a name or other uniquely identifiable personal information). |
|
State Identification Number |
Restricted – NH Data Privacy Act & FERPA (When combined with a name or other uniquely identifiable personal information). |
|
The following elements are considered Directory information:
|
Protected or Unclassified – FERPA – This is not protected and can be openly shared unless asked by the student to be suppressed. Therefore, prior to any disclosure, one must check each student’s FERPA election to determine whether the student data may be disclosed. |
|
Academic Standing (i.e., probation, suspension, etc.) |
Protected – FERPA Note: Students’ entire educational record is considered protected information under FERPA. For example, a class schedule includes information about any student taking a course. |
|
Class Schedule |
Protected – FERPA Note: Students’ entire educational record is considered protected information under FERPA. For example, a class schedule includes information about any student taking a course. |
|
Degree Audit (including courses remaining to complete a degree) |
Protected – FERPA Note: Students’ entire educational record is considered protected information under FERPA. For example, a class schedule includes information about any student taking a course. |
|
Grade Point Average (GPA) |
Protected – FERPA Note: Students’ entire educational record is considered protected information under FERPA. For example, a class schedule includes information about any student taking a course. |
|
Grades |
Protected – FERPA Note: Students’ entire educational record is considered protected information under FERPA. For example, a class schedule includes information about any student taking a course. |
|
Transcript |
Protected – FERPA Note: Students’ entire educational record is considered protected information under FERPA. For example, a class schedule includes information about any student taking a course. |
|
Student Identification Number (EMPLID) |
Protected – FERPA – Unlike a staff and faculty member EMPLID, a student identification (ID) number is Protected Data and requires protection under FERPA. When a student worker’s EMPLID is used for employment, this EMPLID remains protected by FERPA. – This ID number is not a personal identification number under the NH Data Privacy Act and is not protected by that law. |
|
Information on former students – Student records not to include SSN or Driver’s License/State Identification Number |
Protected – FERPA – Educational Records collected when an individual was a student is protected in accordance with FERPA, for the life of the record. Protected FERPA or Unclassified – Information that was collected as directory information when an individual was a student is not protected unless asked by the student for it to be suppressed, while the individual was a student. Not classified by FERPA – Information about a former student (i.e. alumni information) collected after the student graduated |
Donor Information
|
Donor Information Elements |
Information Classification |
|
Social Security Number |
Restricted – NH Data Privacy Act & GLBA |
|
Bank Account Number |
Restricted – NH Data Privacy Act & GLBA |
|
Financial Account Information |
Restricted – GLBA or Payment Card Industry Data Security Standard (PCI or PCI-DSS) – Not to be stored without specific permission. |
|
Name |
Protected – When associated with donation(s) not made public |
|
Giving History (Amount/what donated) |
Protected – When associated with donation(s) not made public |
|
Address |
Protected |
|
Telephone/Fax Numbers |
Protected |
|
|
Protected |
|
Employment Information |
Protected |
|
Family Information |
Protected |
|
Interests, Affiliations or Sports |
Protected |
|
Other donor info (e.g. Age, Sex, Degree Information) |
Sensitive |
Payment Card
|
Payment Card Elements |
Information Classification |
|
Credit/Debit Card Number |
Restricted – PCI-DSS & NH Data Privacy Act |
|
(Primary Account Number – PAN) |
Restricted – PCI-DSS & NH Data Privacy Act |
|
Cardholder Name |
Restricted – PCI-DSS & NH Data Privacy Act |
|
Expiration Date |
Restricted – PCI-DSS & NH Data Privacy Act |
|
Service Code |
Restricted – PCI-DSS & NH Data Privacy Act |
|
Authentication data |
Restricted – PCI-DSS – Never to be stored. |
|
Card Verification Code or Value (CAV2/CVC2/CVV2/CID) Number |
Restricted – PCI-DSS – Never to be stored. |
|
Personal Identification Number (PIN/PIN Block) |
Restricted – PCI-DSS – Never to be stored. |
|
Full Magnetic Stripe Data |
Restricted – PCI-DSS – Never to be stored. See |
|
Masked Credit/Debit Card Number (no more than first 6 and last 4 digits) |
Sensitive |
Procurement
|
Procurement Elements |
Information Classification |
|
Pre-Award Contract Bids |
Protected |
|
Awarded Contracts |
Sensitive/Public – Freedom of Access Act (FOAA) – subject to public record requests. |
|
Purchasing Card (P-Card) Numbers |
Protected – P-Card protection requirements differ from payment cards accepted by a university merchant activity. However, all credit card numbers are high target theft items. |
Information Security
|
Information Security Elements (IT) |
Information Classification |
|
Authentication Credentials (such as a password key or token) |
Restricted – Requires the same protection as the level of information that is protected by those credential |
|
Access & Authorization Information |
Generally Sensitive – May Require the same protection as any information that could lead to unauthorized access at the level of information that is protected by a system |
|
Vulnerability Scanning Results |
Generally Sensitive – May Require the same protection as any information that could lead to unauthorized access at the level of information that is protected by a system |
|
Risk Assessment Results |
Generally Sensitive – May Require the same protection as any information that could lead to unauthorized access at the level of information that is protected by a system |
|
Intrusion Detection Alerts |
Generally Sensitive – May Require the same protection as any information that could lead to unauthorized access at the level of information that is protected by a system |
|
Security Architecture & Design |
Generally Sensitive – May Require the same protection as any information that could lead to unauthorized access at the level of information that is protected by a system |
|
Security Incident Response |
Generally Sensitive – May Require the same protection as any information that could lead to unauthorized access at the level of information that is protected by a system |
Other Data
|
Other Data Types |
Information Classification |
|
Export Control Research |
Restricted – International Traffic in Arms Regulations (ITAR), Export Administration Regulations (EAR) – Specific elements not listed. Requires additional protection. Refer to appropriate regulation. |
|
Human Subject Research |
Depends on Research- Common Rule (45 CFR 46, 102(d)) - |
|
Department of Defense (DoD) Controlled Unclassified |
Restricted – Requires additional protection. |
